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
--
Trevor DeVore
Blue Mango Learning Systems
ScreenSteps: http://www.screensteps.com
Releasable Revolution Resources for Developers:
http://revolution.bluemangolearning.com
_______________________________________________
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
