Force completion of script

[innodat]

I just spent a good hour reading past posts, but I have not found a conclusive answer. There MUST be one...

I understand why scripts are allowed to run subsequently. It makes a lot of sense. But what if I have a situation where a user should not continue with another script (through clicking a button on the user interface) before the original script has finished? I don't believe this necessarily means bad design. I can think of plenty of situations that necessitate this.

I'll repeat the question differently: I'm looking for a way to temporarily prevent users from executing scripts, so that a running one can finish in peace. Has anyone found a way to accomplish that? If so, PLEASE share!!!

Thanks,

Michael

PS: Hiding scripts menu with a custom menu doesn't work for buttons on layout - at least not in FM11

[bcooney]

It would be helpful for you to describe an actual scenario.

[bruceR]

I just spent a good hour reading past posts, but I have not found a conclusive answer. There MUST be one...

I understand why scripts are allowed to run subsequently. It makes a lot of sense. But what if I have a situation where a user should not continue with another script (through clicking a button on the user interface) before the original script has finished? I don't believe this necessarily means bad design. I can think of plenty of situations that necessitate this.

Then why did you design the system to leave the user on a layout where these buttons are available?

[innodat]

Then why did you design the system to leave the user on a layout where these buttons are available?

It would be helpful for you to describe an actual scenario.

No problem, this is quite simple: If you have a slow internet connection and accessing a database through fmnet, pretty much any longer script is at risk of being interrupted. That is if you have navigational elements (buttons) on screen, which I consider likely to be the case if your solution has a convenient user interface. Sure, I could add a process window, but to do this for every only slightly more complex task seems silly.

If you feel I got it all wrong, feel free to tell - might be an interesting discussion :-)

[bruceR]

If you want to practice more robust scripting you will have to practice more robust scripting. There is not going to be a simple answer.

You are aware of the Allow User Abort On/Off command, right?

Barbara (bcoony) will have to speak for herself but I suspect she meant a more complete description of the kinds of scripts you're running that shouldn't be interrupted.

[innodat]

If you want to practice more robust scripting you will have to practice more robust scripting. There is not going to be a simple answer.

You are aware of the Allow User Abort On/Off command, right?

Barbara (bcoony) will have to speak for herself but I suspect she meant a more complete description of the kinds of scripts you're running that shouldn't be interrupted.

Yes, I am, but I don't see how this solves this problem. Even with User Abort Off, clicking on a navigational button will either exit, pause or resume the current script. In the first case, we're done for. The second, in limbo. The third, it continues AFTER the user was taken to a new Layout - very bad.

[bruceR]

Yes, I am, but I don't see how this solves this problem. Even with User Abort Off, clicking on a navigational button will either exit, pause or resume the current script. In the first case, we're done for. The second, in limbo. The third, it continues AFTER the user was taken to a new Layout - very bad.

But that's the robust scripting part. There is no option or preference or plugin that reads the developer's mind and the user's mind.

It solves the problem if you take the user to a layout where they do not have these buttons available and lock them there.

It is YOUR choice to set up buttons to do what you want; and attach scripts to them; and choose what those scripts do.

For instance, your important script could set a global variable $$busy and all your buttons can be pointed to scripts which as their first action, check for this property. In general no buttons should perform "instant actions" - they should all point to scripts.

[innodat]

But that's the robust scripting part. There is no option or preference or plugin that reads the developer's mind and the user's mind.

It is YOUR choice to set up buttons to do what you want; and attach scripts to them; and choose what those scripts do.

For instance, your important script could set a global variable $$busy and all your buttons can be pointed to scripts which as their first action, check for this property. In general no buttons should perform "instant actions" - they should all point to scripts.

They all do point to scripts, including record creation, duplication, etc. Without this I couldn't relink keyboard commands to entries in custom menu sets - so that's a given. I just wish there was a checkbox in the scrips dialogue, like "run with full access privileges" that reads "force completion of script", or something the like... since there isn't, I thought maybe someone figured out how to do it with a workaround? That's the motivation for posting.

Thank you for the tip about setting a global variable. I have used this before with OnLayoutLoad triggers and scripts which (silently) switched between layouts. It didn't occur to be I could use it here. I just dislike the fact that I have to alter all the "other" scripts to accommodate the one which shouldn't be interrupted...

[bcooney]

Hi, back from an all too brief vacation. Yes, I was asking for an actual script to possibly uncover why you're prey to interrupted scripts. Three thoughts immediately jump to mind:

1. For scripts that you know will take a while, you really must take the user to a layout that doesn't offer any buttons which'll interfere in the script's processing.

2. Are you familiar with "transactional" scripting? Basically, if you intend to edit records and it is important that they are either all done or none are changed, then you must script accordingly. Best blog imho about this robust scripting technique is from Todd Geist: Geist

3. Consider moving heavy processing scripts to server scripts.

[innodat]

Hi, back from an all too brief vacation. Yes, I was asking for an actual script to possibly uncover why you're prey to interrupted scripts. Three thoughts immediately jump to mind:

1. For scripts that you know will take a while, you really must take the user to a layout that doesn't offer any buttons which'll interfere in the script's processing.

2. Are you familiar with "transactional" scripting? Basically, if you intend to edit records and it is important that they are either all done or none are changed, then you must script accordingly. Best blog imho about this robust scripting technique is from Todd Geist: Geist

3. Consider moving heavy processing scripts to server scripts.

Thank you so much for your input. I just read the article about Go - eyeopening. Specially the information about interrupting phone calls and record commit. I will definitely read more about transactional scripting. I don't think this would solve my problem though, because users will wonder why an action they applied was not executed.

I followed your advice and layered a "Process" window on top of the main window with a nice HTML indicator.

Progress Window.mov

[bcooney]

I've reworked many scripts to be transactional, and it is essential for robust FMGo development.

As for user feedback if a transactional script fails, a simple dialog with a "There was a problem processing....try again?" usually does it.

Your Progress Window idea is really nice, but be careful to ensure that it appears in a modal window.

[innodat]

Thank you - for the compliment and all your help, including the tip about the window being modal. I'll check...