Just spent over an hour (FRUSTRATING!!!) trying to figure out why this simple little two line procedure works fine in Pan 6 but fails to update the data in the field called “paid"in Pan X:
OkCancel “Mark invoice PAID?”
paid=?(clipboard()=“OK”,“PAID”,”")
I finally decided to look at the Clipboard and it shows “Ok” (upper and lower case as you see)
When I changed the procedure to this, it then works:
OkCancel “Mark invoice PAID?”
paid=?(clipboard()=“Ok”,“PAID”,"")
Bug or feature?
Well, it behaves the way its documentation says it does (in both Panorama 6 and Panorama X.) By that standard, the bug was in Panorama 6.
I’d say it was a documentation error in Panorama 6, which led to a bug in Panorama X, since the stated intention was backward compatibility. AlertOkCancel is recommended for new code.
Yes I know but apparently case was ignored in Pan 6 but is not in Pan X. That should be noted in the documentation I would think. I did switch to AlertOkCancel at one point thinking that would solve it but obviously case is still important.
You could use
paid=?(clipboard() match “OK”,“PAID”,”")
as match isn’t case sensitive (matchexact is).
Your code is testing for equality. That is a case sensitive comparison in both Panorama 6, and Panorama X. The difference is that, despite its documentation, in Panorama 6 the buttons read OK and Cancel, and those were the values put in the clipboard. Panorama X did what the documentation said Panorama 6 was doing, rather than what it actually was doing.
Another strategy to consider is to use an Alertsheet statement where you are using the many modal dialogs that we had to use in Pan 6. It is my preference just because I like having the sheet drop down and you can switch to other windows while the alert dialog is being displayed. So in your example you would use
Alertsheet “Mark invoice PAID?”,"Buttons","Ok,Cancel" // or OK
If info("dialogtrigger")=“Ok" //or OK
paid="PAID"
endif
The buttons are programmable, i.e., what they display can depend on the data. For example, you could have a button that displayed the current month, the prior month, or something else related to the data. Then next month, it would automatically update.
This is a bug.
The statement returns the actual name of the button that was clicked. In Panorama 6 the button name was “OK”. In Panorama X the button got renamed to “Ok”, so that’s what it returned. The CancelOk, AlertOKCancel and AlertCancelOK statements also have the same problem. I think Dave is correct that the source of the problem was an error in the Panorama 6 documentation. For the most part, Panorama X was not converted from the Panorama 6 source code, it was rewritten by referencing the Panorama 6 documentation and by testing. In this case I obviously followed the documentation and did not actually test how Panorama 6 worked. Writing Panorama X was a huge project and perfection was not possible.
I have corrected the button name for all of these statements, so in the next release the button will be named “OK”. Of course this means your fixed code will stop working when that release comes out!
Personally I almost always use the match operation instead of = in this situation, since it is case insensitive. If you use the match operator you won’t have to worry about this issue ever again. Here is this code rewritten to use the match operator.
OkCancel "Mark invoice PAID?"
paid = ?(clipboard() match "OK","PAID","")
Here is the help for the match operator.
Great! Thanks Jim, I’ll make the changes. May I suggest however, that you change the documentation to also include this handy alternative for the = sign. In reading the info I see no indication of that.
Thanks for the heads up! I checked my code for those three statements and changed all my applicable = to match operators. It’s probably worth mentioning this in the next version’s release notes as someone will trip over the change.