When asking for help, please do NOT use Perform Find[ restore ].
It does not reveal what is actually happening and just makes the work of helping you much more difficult.
It is vague, confusing, and unspecific And usually requires several back and forth notes.
Explicit scripted finds are IMMEDIATELY readable, first pass, by everybody.
The Find Restore step has a a specified match field that it looks for. When the script is separated into 2 scripts they work flawlessly (testing one at a time). I'm attempting to join them into 1 script that will perform the 2 similar tasks.
I should add that the Perform Find Restore steps (there are 2 in total) differ between part 1 and part 2 of the script. I'm thinking that perhaps the found set is remaining from part 1 and carrying over to part 2?
Write the Find this way:
enter Find Mode [ pause:off]
//use as many set fields as needed
perform find [ ]
then everyone can clearly see what criteria you are using in the Find.
You could also open dialogs to show the actual stored criteria.
The fact that they work when run separately tell me you got a local variable that not being reset.
Have you tried run script part2 at the end of the first script?
"The Find Restore step has a a specified match field that it looks for."
EXACTLY the point.
WHY waste everybody's time explaining this in multiple messages and on top of that HIDE what you are doing, from us, and from yourself. Then you might post another script; claiming to have fixed the problem; when you have not.
I should add that the Perform Find [ Restore ] steps ...
You should NOT need to add ANYTHING.
The script should be IMMEDIATELY READABLE.
Which it will be if you use scripted finds.
Also: $Row is never set. Your script goes nowhere.
Thanks for the insight Bruce. I'm so new at this (1-1/2 weeks new - I'm changing my user name to Bambi) that I didn't know you could use a Scripted Find.
Thanks to Phil, I understand the concept now and I agree that this approach is way more transparent, thus reducing the chance of silly hidden errors. I will correct this in my script posthaste.
As for the $row variable; the script is initially executed while focus is in a portal row. My (limited) understanding is that Get(ActivePoralRowNumber) will return a value that's equal to the portal row that has focus. My intention was to create the variable $row, so that I could direct focus later in the script back to the portal row.
Again, lots to learn. Perhaps you can educate me on this conception (or misconception)?
I missed the spot where you declared it - and you did in fact declare it.
So; sorry about that.
However; walking rows is fragile and there are better ways to do things.
The abhorrent Perform Find [Restore] malfactor has been corrected (thanks for the sample Phil).
Onward: I employed a wonderful tool called the Script Debugger (gold star to the inventor of that beauty) and discovered the offender.
In part 2 of my script there's a step - Go to Layout ["Income Edit" (income)]. This step is required to set various fields in the Income Edit layout fields during part 2 of the script (this happens in part 1 as well).
Upon leaving the Members portal, this triggers the script to start over due to the script trigger that's tied to exiting the portal - i.e. calling the start of the very script I'm trying to run. Ouch. Hence, the, "dog chasing his tail behaviour", looping.
If I can suppress the (normally desired) script trigger upon exit of the portal - only while performing the second step (part 2) of the script, I'm guessing the script would continue to the end and Bob's Your Uncle.
Is there a way to suppress this trigger while mid stride in the script or should I just hang it up and go back to selling shower curtain rings?
Please show us the complete corrected script. (As it exists so far).
Yes; there are ways to deal with script triggers.
Though you should be able write a properly functioning script, even one that does inefficient things - there are better ways to do all of this.
If we can figure out what it is that you are trying to do.
Excellent news! Thanks Bruce. I will take some time to provide a concise description and include the latest script....tomorrow.
Phil did elude to an other solution that involved a TO, and likely the better approach, but this exercise is providing valuable insight to scripts for me and I want to see it through for education sakes.
I appreciate your help.
Is there a way to suppress this trigger while mid stride in the script …
Yes there is. Here's what you do:
1. At the start of the script that gets triggered, add an escape clause such as—
If ( $$triggerOff = 1 )
2. At the point in your running script where you are tripping this script, add a step to set the above variable—
Set Variable [ $$triggerOff ; 1 ]
3. At the first suitable point in this script, make sure you zap the global variable thus—
Set Variable [ $$triggerOff ; "" ]
This process means that (1) when the triggered script is triggered in the normal course of events it runs as usual; (2) setting the global variable just before it would be triggered as your main script runs, means that when triggered from within this script it is diverted from running by the presence of the global variable; (3) as long as the global variable is zapped as soon as possible it will not hang around to trip up any other processes in which you utilise this technique—and once you've seen its possibilities you will no doubt use it elsewhere.