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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
