Popup menu selection
ambassador at fourthworld.com
Thu Feb 18 12:57:21 CST 2010
Trevor DeVore wrote:
> On Feb 18, 2010, at 10:33 AM, Richard Gaskin wrote:
>> To counter this, Ken Ray and I have adopted a habit of using a
>> handler like this one to set an option control's current choice:
>> on SetOption pBtnName, pNum
>> lock messages
>> set the menuHistory of btn pBtnName to pNum
>> unlock messages
>> end SetOption
> One small suggestion. It is a good idea to restore the lockMessages to
> it's original state when setting the property in a library call.
> Unlike lock/unlock screen the engine doesn't keep track of how many
> times lock/unlock messages has been called. Messages are either locked
> or not.
> Restoring the state can save headaches later on if you had messages
> locked before calling SetOption and can't figure out why messages are
> locked after calling it.
> on SetOption pBtnName, pNum
> put the lockMessages into theMsgsAreLocked
> lock messages
> set the menuHistory of btn pBtnName to pNum
> set the lockMessages to theMsgsAreLocked
> end SetOption
Good catch. One of the downsides to writing code off the cuff to the
list rather than digging up my library is overlooking important details
like that. Thanks for the more complete version.
While looking into the lockMessages property recently I came across this
The lockMessages property is automatically set to false when a
palette, modeless, or modal stack is opened, even if a handler
is still running.
This struck me as a bit odd. I can understand why it's like that for
modal dialogs, since they more or less operate as though in their own
event loop. But palettes? Is that useful?
Rev training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
revJournal blog: http://revjournal.com/blog.irv
More information about the use-livecode