I'm pretty sure Halt Script is what you need to use inside the called script. That should prevent it from going back to the calling script, if memory serves me correct. Of have you already tried that?
I just tried and seemed to have fixed my problem. Thank you! If I have problems with it again, I'll come back, but that seemed to have worked. Thanks!
Yes-sir! Glad I could help out.
You can use Halt Script instead of Exit Script.
But that's bad practice. The best approach is to structure your scripts so that each has a single point of exit. And each process (or, more specifically, script chain) should have a single point of exit too. You can use the Result feature of the "Exit Script" step to pass information from sub-scripts to parent scripts to facilitate this.
I find that structuring scripts and processes correctly is one of the trickiest things to master in software development. So Halt Script is handy if you're in a hurry.
halt script is the last resort.
Will kill a whole chain of calls and ontimerScripts, too.
It's an atomic bomb.
Why is Halt Script an atom bomb? I am the developer for a landscape company, so let me give you an explanation of how I am using it. So, originally, the developer before me made a scheduling system where crewmen can schedule their work before performing it. A button is used to find the current day in a table to see if there are any scheduled projects for that day. However, the crewmen struggled remembering to schedule their work, so I developed a way using a few of the original scripts that they could create a work-order on site. The steps are as follows:
- Crewman selects "Perform Work Now"
- Script finds the current day to see if any work orders are already scheduled.
- If work orders are found, a sub-script does a few things and shows a custom dialog giving the option to either complete the found work order or continue to create a new work order.
What I need is for the sub-script in step three to be able to, if the crewman chooses to complete the pre-scheduled work, stop everything because he is exactly where he needs to be.
I did the Halt Script and it seemed to solve the problem, but as with any database, I can't afford for it to be destructive to anything. So, is it really that bad in this case, and, if so, what would be your replacement suggestion?
I'm sorry if I was misunderstood.
Halt script does not nuke data; it nukes the script engine by essentially telling it to wipe all running and waiting and calling scripts. And scripts sometimes have a commit instruction, which might be turned off by your halt, resulting not in bad data but in missing data.
In your specific case, IMHO you're trying to control too much.
2) NOK. The script finds, yes, BUT DISPLAYS, in a way comprehensible to the user, the situation.
now the ball is @ user.
3) NOK, the user should have at his disposal all the elements useful for deciding what to do. He might go for a hamburger, come back after 30 mins and decide option 1 or option 2, present on screen but not elements of a custom dialog.
No need to halt anything, as nothing should be running between screens showing options.
P.S. Custom dialogs suck - they disrupt flow. Always.
P.P.S. While your custom dialog is displayed, the situation of the whole database might change behind the scenes because another user from a different terminal actually makes choices and changes data.