More Dialog Questions

How can you limit the entry a user makes in a dialog edit_box? With sliders
it's easy: there are min and max value attributes.
But what if you want to prohibit, say, negative numbers, or non-numbers, or
non-integers, etc.

Also is possible to have the contents of one edit_box update as the contents
of another are filled in, if the two have a mathematical relationship?

 

Michael, I'm not sure how to post files to the server. I have a small
sample dcl and lsp that I think will help. If you reply to me as opposed to
the group, I will send them.

Regards,
Pete

 

Michael, I have a small sample dcl and lsp that I think will answer both
questions but I'm not sure how to post files to the server. Reply to me and
I'll send them.

Regards,
Pete

 

I'd do this in on the lisp side. One of my dcl files includes:

{
label = "AFC" ;
: edit_box
{
key = "AFC" ;
action = "(setq available_fault_current $value) (test_values)" ;
}
}

The test_values function is:

(defun test_values ()
(if (and (/= AWG "")
(/= available_fault_current "")
(/= voltage "")
(/= conduit_length "")
)
(mode_tile "accept" 0)
(mode_tile "accept" 1)
)
)
In this case the test_values function only tests to be sure all fields
are filled in, but it would be easy to rework to test each string and
reset the tile to either nil or to the default value if the entry is out
of range. You might need to add either an alert or a text field to
inform the user that there was a problem with the entry.

You could use the same technique as above. Do the calculations in lisp
and do a set_tile on the second field. This works when the user leaves
the textbox.


Martin

 

Thanks Martin. Lisp was the only way I could see of doing it too.

This leads me to a question that you might be able to answer....

Say I have a routine that calls a new_dialog, and then goes on for a few
line "initializing" the tiles (setting modes and initial values). Then it
goes on to set action_tile properties, before going on to start_dialogue.

It's not until this point that the dialog actually appears, and is available
for data entry. Between the start_dialog and the time the dialogue is
"retired" what is actually happening? How is it that the action_tile calls
are executed after they've been passed in the execution of the lisp code?

From the "retirement" of the dialog, it seems pretty straightforward to me,
but before then I confess to pretty extensive bewilderment...

So, for example, when we spoke of having one tile's value determined by a
value entered into another tile, through the intercession of lisp code,
how/why is that lisp code run while the dialog is still active, and what is
happening to the queue of lisp code still waiting to be executed? The two
processes, lisp and dcl, seem at times in series and at other times
parallel.

 

"Between the start_dialog and the time the dialogue is "retired" what is
actually happening? How is it that the action_tile calls are executed after
they've been passed in the execution of the lisp code?"

Basically, what happens is whatever actions you have defined for the tiles.
You can have a dialog with edit boxes and radio buttons that trigger other
functions, do calculations, set variables, set values of other tiles, and
nothing else. You can enter values in these boxes, press enter or click the
buttons all day long. The dialog will remain open. Each time you do any of
the above, the action_tile statement associated with the box or button is
called. So there is no consecutive execution of lines of code in the lisp
file. Until you click a button whose action_tile has a done_dialog
function, the dialog remains open. Generally, you're accept button (or ok
or whatever) and cancel button assigns a value to a variable and closes the
dialog. The variable acts as a switch to either execute the primary
function (ie. draw lines) or cancel the routine and unload the dialog
without doing anything. After the task is completed, you can even have the
function load a second dialog that has an accept, modify, and cancel button.
You can have the modify button call a function to undo everything and then
load the initial dialog again so you can make your changes.

Dialogs are interactive. The buttons you push determine what code in the
lisp file is executed and when it is executed.

 

Spooky!

Multiple possible interactions with code being executed in an order
determined by the button-clicker.....<shudders>

I've actually successfully added an error tile and have been able to get
some of the warnings out of the alert boxes and into the error tile, and
then shift the focus onto the problematic tile. There are still some kinks
to work out, but I'm close. Thanks for all the help to both of you.