After getting unexpected behavior while working on a more complicated dialog window, I created a simple database with a simple dialog form with 3 objects: a text edit box, Cancel button, and OK button. The buttons have resume {} as their only code. When I present the form using Rundialog the code below should display my ‘in loop’ message when I hit the OK button but keep the dialog window open. Instead, the window closes and I only get my ‘after loop’ message. Rundialog seems not to be responding to the if info("trigger") contains "Button.OK" part of the code. What the heck am I missing??
[mac os monterey 12.2.1 Pan X 10.2.0.b25 (3901)]
fileglobal fgV01
fgV01=A
loop
rundialog |||
Form="DialogForm"
sheet=true
Menus=normal
Height=780 Width=1060
|||
stoploopif info("trigger")="Dialog.Close"
if info("trigger") contains "Button.OK"
message "in loop ok message"
settrigger ""
endif
endloop
if dlgResult="Cancel"
message "afterloop cancel message"
endif
if dlgResult="Ok"
message "afterloop ok message"
endif
It did that because the standard spelling of that button (according to Apple) is Ok, not OK. Since you used a non-standard spelling, the Dialog Workshop did not recognize that it actually was the Ok button. You could have gotten it to generate the code you want by using the Ok Button popup menu in the Dialog Options section, as I’ve done here.
My dialog has three buttons, OK, Cancel and Go. The Cancel button is automatically recognized because I used the standard name for that button. If I had picked a non-standard name for the Cancel button I would have needed to specify that name in the Dialog Options panel of the Dialog Workshop.
Notice that there is no code for the Ok and Cancel buttons. These buttons are normally handled automatically, you don’t need to supply any code. You only need to supply code if you want to do some extra validation before Panorama actually performs the Ok or Cancel operation. If you do want that, you look for the triggers Dialog.OK or Dialog.Cancel – NO MATTER WHAT THE BUTTON TITLES ACTUALLY ARE. There are examples of this in the rundialog help page.
Tom suggested that you change Button.OK to Dialog.OK, as shown above, but that is wrong. The settrigger "" line will abort the action, leaving the dialog open. With this code in place, the only way to close this dialog will be pressing the Cancel button. At a minimum you should remove the settrigger line, and unless you absolutely need the message, you should remove all four lines of code.
I must have seen this chart last year because I had already liked this post, but I don’t remember. But having seen it again, bravo, this is a very cool chart.
The code works as intended when you follow my suggestion. It’s true that this example given by Bill would be pointless and would disable the appropriate use of the ok button, but I think he wanted to understand why his code did not know that the OK button had been pressed and do something.
The help page uses the same code to find out if the OK button has been pressed.
It gives this example.
loop
rundialog {Form=“Find” Height=45 Width=346}
stoploopif info(“trigger”)=“Dialog.Close”
if info(“trigger”) contains “Dialog.OK” // has the ok button been pressed?
if findThis=“”
nsnotify “You must enter something to search for!”
settrigger “” // don’t close the dialog
else
select exportline() contains findThis // do the search
endif
endif
endloop
I sure hope you didn’t take my comment personally. If so, I am very sorry, that was the opposite of my intention.
I don’t think it does. The problem isn’t your suggestion, but the original code with the settrigger statement. I would thing the intention would be that pressing the OK button would close the dialog, and with this code, the dialog won’t close.
In that example the code is checking to make sure that pressing the OK button was really valid. If not, the dialog isn’t closed, but if everything is ready to go, the dialog will close. By taking Bill’s original code and simply changing Button.OK to Dialog.OK, clicking the OK button will not perform the task of closing the dialog. So that is what I meant by “wrong”.
Perhaps however, I am wrong, since @billashw says that the modified code did work! It seems to me that if it did work that would be a bug, so I kind of hope it doesn’t
No, I did not take it personally. Just wanted to have a discussion of the issue. Since I made my charts, I have made lots of use of rundialog and think it allows some very nice user interfaces.
I appreciate the conversation! Just to clarify, trapping the user hitting the OK button and preventing the dialog from closing was the purpose of the simplified test routine I posted. The “real” intended use behind this test case was to have rundialog respond to the OK button by first performing a validation check on the user’s entries, and if there were problems to notify the user and keep the dialog window open so that the entries could be corrected, cleared, or Cancel chosen instead. Testing for Button.OK did not work even though that was the wording provided by the Dialog Workshop (and I did try different spellings of ‘OK’). Tom’s suggestion to use Dialog.OK did work. I’ve returned to my original working database (code not posted) and made the change and the validation check is now working as intended. Thanks again!
I will volunteer another strategy that I have used to validate data entered in a dialog before it closes. Upon opening the dialog (if info(“trigger”) contains “Dialog.Initialize”) , I disable the OK button with a changeobject statement. Then I have a validation procedure that checks whether the entries in the dialog meet the criteria, and if they do, the OK button is enabled. The validation procedure is triggered when the user presses return or tab to exit a text editor. This way, the user knows if they have entered valid data before pressing the ok button.
