6 Replies Latest reply on Jun 20, 2010 8:08 AM by ralvy

    Exit [Result: 0] not trapping button press



      Exit [Result: 0] not trapping button press


      I just noticed the following problem. I have a series of script triggers that monitor data entry and, when they see an inappropriate value in a given field, they issue an informative Custom Dialog message and then do an Exit [Result: 0]. They are called on Object Exit. This generally works fine, not letting the user leave the field with inappropriate data. However, I just noticed that if the user leaves the field by clicking on a button somewhere else in the layout, the button script isn't always stopped out. It seems to depend on what's in the button script.  For instance, a button script that simply changes the layout, not calliing other scripts, seems to have no problem.


      I have resorted to having such a script trigger script set a $$StopButtons variable to 0 when it starts, and reset it to 1 if it sees inappropriate data entry, then do an Exit [Result: 0].


      I then placed the following at the beginning of each button script on such a layout:


      Commit Records (not validation an no pause)

      If [ $$StopButtons = 1 ]

          Exit Script

      End If


      This works, but seems rather inelegant. Am I missing something more straightforward that can be done here?

        • 1. Re: Exit [Result: 0] not trapping button press
          Steve Wright

          When you define the button, what option do you have set for the current script's action..

          Im not 100% sure, just taking a wild guess since I have not tested.. but could it be set to halt any running script ?


          Im thinking perhaps the process would go like :


          First button click ( run script 2)

          Trigger activated ( run script 1)

          Second button click (halt script 1 - possibly before it gets to the exit step)

          Continue to run script 2 as per buttons instructions.




          • 2. Re: Exit [Result: 0] not trapping button press

            Actually, in any given case like this, I don't want the field trigger script to halt because the user pressed a button. I want it to keep evalutating the field it's on, until the user gets the data right. It's the button script I want to fail to run if the trigger script sees data in the field that's inapproriate.



            • 3. Re: Exit [Result: 0] not trapping button press
              Steve Wright

              Sorry, I may not have worded it correclty...what I meant to say is :


              Could it be that your button is currently set to halt the script, if so perhaps due to the speed of clicking, it may be halting the triggered script before it gets to the exit[] step.

              • 4. Re: Exit [Result: 0] not trapping button press

                Ah, I understand. No, the button in each case is set to Pause the current script. I also tried Resume, with the same effect.

                • 5. Re: Exit [Result: 0] not trapping button press
                  Steve Wright

                  I may have to do some testing with this myself too... I use this trigger quite a lot.

                  • 6. Re: Exit [Result: 0] not trapping button press

                    One more complication to add to this. In the cases noted here, the script triggered Custom Dialog elicited by inappropriate data input offers the user two choices, not just OK. They are asked which of two fields to fix (usually the conflict is between two date fields, A and B, where B must not precede A chronologically). When they make their choice in the Custom Dialog, they are returned to the field they choose, awaiting their dat entry correction. The script trigger does this over and over again until they get it right.


                    In some cases where I didn't apply my inelegant fix, I found pressing an unrelated button on that layout executed the button script as though the initial script trigger didn't have an Exit [Result: 0} step. In other other cases, pressing an unrelated button on that layout kept placing them back in the Custom Dialog, never leaving them in a field for data correction. All this is resolved with my inelegant solution.