Paul Dupuis wrote:
> Does anyone have a compiled list of which messages need to be passed
> or *should* be passed vs those that you do not have to concern
> yourself with?
"Should" is a tough thing to define, since it'll vary by use.
I usually suggest to newcomers to the language that they develop a habit
of passing everything unless they know why they don't want to.
That guidance is often useful, since if something downstream needs the
message it'll get it, but if nothing needs it no harm is done.
With frontScripts, I believe a stronger recommendation is needed, since
those play a very special role: always pass messages in frontScripts.
Any exception to that must be very carefully considered, and is usually
wrong. Not always wrong, but often enough that problems will usually
result from not passing messages trapped in a frontScript. Only experts
operating in highly unusual circumstances should feel comfortable
trapping a message in a frontScript without passing it.
But for everything else, there's usually no harm in passing, so it's
rarely a bad choice when in doubt.
And when there is it's usually because of conscious choices the
developer has already made (such as overriding centralized handling of a
certain message in a group, card, stack, or behavior script), so they'll
know what they want to do.
There are a few messages for which passing or not passing has very
direct consequences, an inherent part of the decision-making we need to
do as coders.
CloseStackRequest is one of these. It's sent when the user clicks the
close box of a stack, and it used to respond to that action to determine
if the window should indeed be allowed to close. Most often this is
used with a prompt to save document or DB data, with an option to cancel
the close action. When canceled, not passing the message prevents the
window from closing, which is what we want. And if the user chooses to
save or not save, we can save if requested and then simply pass the
message to allow the close action to complete naturally.
In a very broad sense one might see the keyDown/rawKeyDown messages in a
similar light, since passing them allows the user action to complete
naturally.
But since the option to pass or not pass will depend on the specifics at
hand, I'm not sure I could recommend we "always" pass those.
Like the rest of life, coding involves a variety of circumstances that
require us to think on our feet, read what we can to inform our
decisions, and sometimes experiment to make sure we get what we're
looking for.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
