<< It's one of those properties that's reset at idle, so you have to set
it in the actual handler for the first message that gets sent. Also
note that nowadays using the "try--catch" control-structure is
preferred over "lock error dialogs" because it's easier to follow the
logic and easier to handle different errors in different ways.
Regards,
Scott >>
Thanks for the info. I have found that sometimes stacks I distribute will
have minor errors which do not affect the performance of the program (such as
a mispelling in a button name when clicking the button looks for information
to display for that particular name.) In SuperCard, I would lock the
errorMessages so the user would not see them. Thus, for a typo in a button
name, for example, nothing would happen instead of a error message appearing
for the user to see. (After all, even if my stacks aren't perfect, I like
the user to think they are!!) I found that to be very useful whereas, using
"try" would mean going back through the whole program and putting a "try"
statement into every handler.
Regards,
Philip Chumbley
