Popup menu selection

[Richard Gaskin]

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 
note:

     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?

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv