Exiting Loop via Custom Dialog?

[LaRetta]

Purpose of script: Make sure an important document (Deposit List) prints properly before continuing. Custom Dialog presents three options: Yes No Cancel. Script should exit loop on Yes, loop back to print again on No or Halt on Cancel. Script won't exit loop on Yes; it loops again instead like it doesn't see the Exit Loop If [ ].

Allow User Abort [ Off ]

Loop

Set Error Capture [ On ]

Print [ ]

Show Custom Dialog [ Yes ; No ; Cancel Print ; "Did Deposit List print correctly?" ]

If [ Get(LastMessageChoice) = 3 ] [color:blue](Cancel print)

Halt Script

Exit Loop If [ Get(LastMessageChoice) = 1 ] [color:blue](exit loop)

End If

End Loop

Script goes on to do a bunch of important stuff if choice is Yes. I tried adding another If [ ] test if Get(LastMessageChoice) = 1, End Loop (thinking it would work within an If [ ] but it won't take it. And I can't write an If [ ] test if Message Choice is 2!! To do what? Continue the loop? Help would be most appreciated.

LaRetta

[Raybaudi]

Hi, LaRetta

and so ?

_________________________________________________

Allow User Abort [ Off ]

Set Error Capture [ On ]

Loop

Exit Loop If [ Get(LastMessageChoice) = 1 ]

Print [ ]

Show Custom Dialog [ Yes ; No ; Cancel Print ; "Did Deposit List print correctly?" ]

If [ Get(LastMessageChoice) = 3 ]

Halt Script

End If

End Loop

_________________________________________________

You have maded a little error... the exit Loop was nested into an if/endIf :)

[LaRetta]

Okay. Time for a break!

I had also placed the Error Capture[] within the loop. That was no typo. I'm finding that sometimes it needs to be inside because other portions of a script, other loops, or sub-scripts will invalidate the first Error Capture[] and it needs to be recaptured again. But I don't think it's needed here.

I left the sequence the same - didn't change the order and it worked perfectly after moving the Exit Loop If [ ] down one line. Can you explain why you moved it to beginning of loop? I just want to understand your thinking on it. Thank you, Daniele!

LaRetta

[Søren Dyhr]

Hi LaRetta

Aren't you complicating matters unnecessarily??

Allow User Abort [ Off ] 

Set Error Capture [ On ] 

Print [  ] 

Show Custom Dialog [ Message: "Did Deposit List print correctly?"; Buttons: “Yes”, “No”, “Cancel Print” ] 

If [ Get ( LastMessageChoice ) = 2 ] 

    Perform Script [ “Print List Deposit” ] 

End If 

...guessing here that the script is called "Print List Deposit" so it recures!

sub-scripts will invalidate the first Error Capture[] and it needs to be recaptured again. But I don't think it's needed he

Neither do I, but it's taken care of in my script anyway!

--sd

[Raybaudi]

Hi LaRetta

one line down is the same, as you exit the if/endIf

I generally put an "exit Loop" quick after a "loop" for two purpose:

1) visual control (what about if the script were longer ?)

2) ending a loop more quicly ( if it has to exit)

Not to mention that I can forget it ! ???

[LaRetta]

Hi Soren,

Yes, I was overcomplicating. This was a modified process (in attempts to protect from ONE User), thus the loop to contain and control. But I could have contained and controlled (in this instance) just by starting the script over, which would have also negated the need to error-trap again (which wasn't necessary here anyway).

When new, I had used 'same script within a script' and it created a perpetual script fire which required 3-finger salute to get out of and I trashed my design. I have (subconsciously) shied from the concept ever since opting to control within loops instead. I had learned loops immediately after (but not because of) this fiasco.

Thank you for taking the time to provide this simple (but powerful) lesson. I will reevaluate four similar scripts. I now know to leave Allow User Abort [ ON ] until a script is perfect.

LaRetta

[IdealData]

I've never been able to hold on to the last message choice after the next script line execution, so I've always kept the result in a global. I think the same happens with error codes too.

LaRetta, you have Dev 7, why not trace the script step by step.

[LaRetta]

Hi Daniele,

My question stemmed around placement of Exit Loop If [ ]. Why put it first? The visual reason makes sense but the idea concerns me. When the loop is first entered, a test on Get(LastMessageChoice) would get is value from where? Could it be a message choice upline from the loop? 'LAST' message choice implies looking up through a script. I don't feel I could trust it.

I also disagree that it would be quicker ... it still needs to hit the Custom Dialog (and If-test) before an exit can be considered. It is immediately following the test that the exit consideration would be most powerful. Placing it first is actually further down through a series of tests - to the end of the loop before it begins the loop again and will hit that Exit Loop If [ ]. I realize it's kinda like hunting for the beginning of a circle but I think order matters.

This script is not a good example, I'm afraid (with only a Halt, Exit Loop or Loop option). I may have to devise a script with complex If [ ] tests (and multiple branches) to notice any speed differences in this script-step placement! And I will test a Custom Dialog prior to a loop to see if theory holds (whether FM means LAST within loop, last within script, or ?). Because asking for test results before a test feels wonky and might skew your results.

Update: If using Exit Loop If [ ] , I think the tester should consider what value FM may be holding at that moment. Because it may not be the same as what you implied later in the loop. First entering a loop would be good example of when it might break if placed at the beginning. This is speculation. I have not tested any of this reasoning yet.

LaRetta

Edited October 30, 2005 by Guest

[LaRetta]

Hi Mark,

I use debug all the time. And used it here. But it just showed it doing what I knew it was doing - looping again. I simply missed that it was inside an End If [ ] and, if not overly tired, I'd have noticed it. Sometimes debug doesn't provide me answers, unfortunately. Debug can't protect me from all DOH moments.

I've never had to capture Get(LastMessageChoice) in global - it's always worked perfectly. I HAVE captured errors within globals though!!

LaRetta

[Raybaudi]

I generally put an "exit Loop" quick after a "loop"

Generally isn't always !

But look this:

Set field [count=1]

Loop

Exit Loop if [count > 10]

other instruction

other instruction

other instruction

other instruction

other instruction

Set field [count = count +1]

End loop

it is the same of:

Set field [count=1]

Loop

other instruction

other instruction

other instruction

other instruction

other instruction

Set field [count = count +1]

Exit Loop if [count = 10]

End loop

For me the first one is more comprensible :)

[LaRetta]

Ah but Daniele.

It works because your test is on a record. Get() functions are not loop- or record-specific, necessarily.

I understand what you're saying, I'm just pointing out that using Get(LastMessageChoice) test for an Exit Loop If [] might produce incorrect results if put at the beginning. Because a User might have selected choice 1 prior, in a Custom Dialog script-step above somewhere. And answer '1' above may not be what you want to happen with answer '1' inside that loop for your next Custom Dialog! If you ask for an answer before the question (putting Exit Loop If[] first), be sure you know what FM will give you.

Speed issues would apply just as in a calculation such as Case() or If(). Branch prediction (deciding which action is most likely and the quickest) would always come into play and should dictate the quickest way out. Quickest way out is immediately after the Custom Dialog test. Your example doesn't change my mind on that.

L

[Raybaudi]

I'm just pointing out that Get(LastMessageChoice) would not be good to put at the beginning.

This is veeery correct ! ;)