Window Focus

[faada]

Need a lil help here, I am using a button to call a new window (and create a related record) for the user to enter data into, the data entry window has 2 buttons, 1 to save the data and close the window, the other to cancel the data entry (delete the created record) and close the window.

I have realised that an errant mouse click will leave the data entry window open but hidden behind the main window, is there a way to keep the focus on the data entry window until the save or cancel buttons are pressed?

'preciate it

[aklodner]

In the script where you call the new window, put a pause script step in there after you call the new window. This will "freeze" the window. Then, when you specify your save or cancle buttons, have them resume current script. This will kill the pause.

One last note, make sure to use Allow User Abort (off) script step in the script that's calling the new window. If you don't, a user can still click on the close window button and get out of that window. Not only do they get out of the window, but your paused script then carries over to the next active window.

HTH,

Adam

[CobaltSky]

Hi faada,

The suggestion Adam has made includes the requirement for an 'Allow User Abort [Off]' step in the calling script, to block the user's escape routes. However he overlooks the fact that with the script he has suggested, if the user presses the Enter key or clicks the 'Continue...' button in the Status Area (assuming it is accessible), the paused script will resume and the lock will be released - and then you're back where you started.

An alternative method which would address this issue would be to conclude your calling script with the steps:

Loop

Pause [indefinitely]

End Loop

...and then specify your save and cancel buttons to 'Halt' the current script rather than resuming it.

The effect will be similar - the window will be locked in front - but you will have closed one more 'loophole' through which the user can escape.

Please note that even with this refinement, the solution may not be water-tight. For instance, of the user accesses the database using the 'Panther' version of OS X, they will still be able to escape the front-most window using the 'Expos

[Fenton]

Another rather large "gotcha" is that scripts in the Scripts menu can still run when you're paused. In v6 you had to set a global field as a "flag," to 1, then clear it with any buttons that could stop the Loop, or test for the current layout (we only had 1 window per layout way back then :-).

In 7 (and I just learned this, by looking to see what could be done) you can use the step (from Help):

Get(AllowAbortState)

Returns 1 if Allow user abort script step is on, otherwise returns 0

Add that as an If test at the beginning of every visible script. It seems like a good idea anyway really. How often would you want people to run another script from the Scripts menu while you have Allow User Abort ["Off"]?

I guess in your case you could also use a test on the name of the current window. But I like the above. Anyone see a problem with it?

PauseLoop.zip

[321]

I am also concerned about windows being left open. I'm not extremely proficient at looping, so instead I used the halt scrip to close the window after pausing for 4 seconds. (So if you interact with the new window, you have 4 seconds before the window closes or if you make a selection it closes as well)

See the attached file.

DateSelect.zip

[faada]

Great suggestions and thanks Adam and Ray and Fenton. For now I will be using the combination of Adam and Ray's suggestions, right now I don't have any scripts that I allow the users acces to in the script menu but Fenton's suggestion will be useful in the future.

Again, thanks all.