Should I use a modal dialog?

[cmhjon]

Hi all,

I have a main stack that calls a simple substack that contains a few text fields, an "OK" button, and a "Cancel" button. Based on input from the user, this substack/dialog is called x number of times (in a repeat loop) with the 'OK' button putting the users text field responses into variables and closing the substack.

I need for the script to wait until the dialog has been displayed (the user selected number of) times and text field responses recorded each time. It seems like opening the substack as a modal (modal stack "substack") would be the way to go but when I click OK, the substack does not vanish and LC seems to lock up. I tried just "go to stack 'substack'" but the script continues to execute without waiting for the substack/dialog to be answered by the user which of course results in script errors.

I also need to ensure that if the user clicks 'Cancel' in the substack that the parent script outside the substack is also aborted.

Should I use a modal dialog? What line(s) of code do I need in each button to make this work?

Thank you,
Jon

[dunbarx]

but when I click OK, the substack does not vanish and LC seems to lock up.

I think we need to see a bit of the code, or maybe you can post the stack. The mode is not the issue.

After that, what mode you use is a matter either of style or of substance.

Opps, that covers everything, doesn't it?

Craig

[richmond62]

Surely the point of using a modal dialog is to stop the end-user from clicking
on the main stack until whatever is on the modal dialog has been seen to?
-

[stam]

I need for the script to wait until the dialog has been displayed (the user selected number of) times and text field responses recorded each time. It seems like opening the substack as a modal (modal stack "substack") would be the way to go but when I click OK, the substack does not vanish and LC seems to lock up. I tried just "go to stack 'substack'" but the script continues to execute without waiting for the substack/dialog to be answered by the user which of course results in script errors.

Hi Jon, I think I would have gone about this in a different way.
It sounds like your collecting data in a loop. Without specifically knowing your code it sounds like you’re hoping to “suspend “ a loop until user has inputed data and then either continue the loop which would bring up the modal dialog or stop.

The modal isn’t the issue - it prevents input in the parent stack but doesn’t just stop a loop from running.

I wouldn’t do this in a loop. Instead I would have considered creating script or global array variables (not in a loop) and instead just refreshing values in the modal until it’s dismissed if that makes sense. And on closing the substack it passes the arrays back to a command/function the main stack.

Passing variables in functions/commands may be a better option (ie the parent stack would call a function in the modal substack passing variables needed for the substack to work, or if that’s not feasible just use global variables.

Perhaps if you post the scripts used to call the substack and process the user input, forum readers may be able to suggest a better model.
But as far as modal or not goes, that’s probably the correct style to use if you want to stop users from doing anything else until clicking “OK”...

[cmhjon]

Hi stam,

You are correct. After posting this, I got to thinking about this more and ultimately came up with the following:

For the 'OK' button in the main stack:

Code: Select all

on mouseUp
   global vCounter
   global versionsCount
   put 0 into vCounter
   ask "How many verions?"
   put it into versionsCount
   go to stack "User Input"
   select char 1 to -1 of field "Page Width" of stack "User Input"
end mouseUp

For the 'OK' button in the "User Input" substack:

Code: Select all

on mouseUp
   global vCounter
   global versionsCount
   if vCounter = versionsCount then
      # code to verify and record the entries will go here
      close this stack
      # code to call the sub routine that will finish the job will go here
   else
      # code to verify and record the entries will go here
      # code to reset the 6 text fields by putting empty into them will go here
      add 1 to vCounter
      select char 1 to -1 of field "Page Width" of stack "User Input"
   end if
end mouseUp

The substack interface stays open until the user has entered all the requested specs for each of the versions (the number in the 'versionsCount' variable) and when the two variables match each other, the script closes the substack and finishes the job.

Best regards,
Jon

[stam]

Glad you found a solution Jon!

It's a (personal) style thing, but it may make code a bit simpler to declare the globals outside of the handlers, eg:

Code: Select all

global vCounter, versionCount

on mouseUp
...
end mouseUp

Because you'd need to declare the globals in every script they're used, I do this and then just copy the 'global' line and paste it where needed to avoid mistakes etc. Plus there's less code inside the handler

[cmhjon]

Hi stam,

Good to know! Thank you

Cheers,
Jon

[dunbarx]

About those declarations. They must be made ABOVE any handler that needs them. So it is a matter of style, but I always place both global and script local variables at the very top. Others might place them above the handlers that use them.

Craig

[stam]

Yes I do the same - should have mentioned it as well, the declarations are on the top of the script.
If nothing else it means I know where to find them right away, but Craig makes a valid point...

[dunbarx]

I can't find the milk in the refrigerator. I have to place all declarations at the top.

Craig