When is message passing required?

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com