keyDown, the final chapter

[Richard Gaskin]

DunbarX wrote:
> The following flies in the face of everything we just anguished over.
> 
> Nothing in the stack script. This in the field script...
> 
> on keydown
>     send "beep" && "3" to this stack
>     --dispatch "beep" to this stack with "3"
> end keyDown
> 
> Comment either as you see fit. Type a char.
> 
> "Send" works (that is, beeps) and "dispatch" does not. Go figure. And just 
> when I was getting used to it all.

As Sarah pointed out, if you want to get a useful result just do this:

on keyUp
   beep 3
end keyUp

There you have it:  your character goes in the field and you get three 
beeps afterward.

If instead you want to find the boundaries of the engine's sanity, this 
way madness lies. ;)  There are no doubt inconsistencies in all the 
xTalk dialects, and RevTalk is no exception.

But there appear to be at least some basic rules you can use to navigate 
this jungle:

- Handlers handle messages

   If an object has no handler for a message, it has no way
   to handle that message.


- Messages can only be successfully sent to a script that has a
   handler for them.

   If you want a specific object to handle a message, give that
   object a handler for it.


- You can send built-in commands (as distinct from messages)
   to objects which have no handler for them.

   Since you can't define your own custom commands of the same
   name as a built-in command, this is consistent with the
   Raney fixation on pruning the message path to the essentials,
   since commands aren't messages per se.

   It's really just another way to call a command, but does so
   in a way that changes the target.

   If you don't need to change the target (such as in your example
   above) it's often simpler to just call the command from the
   script that needs it rather than slowing down both its
   performance and your typing by sending it to another object.


- Dispatch will send anything to any object, but will only
   trigger handlers which exist in the destination object's
   script.

   This is as described.  Dispatch is the most recent addition
   to the language as far as message-path-altering commands go,
   and was added primarily for behaviors to be able to send
   messages to instances (though it can be useful in many other
   contexts as well).

   The Dictionary entry for the dispatch command notes that the
   local variable "it" will contain one of these three strings
   after dispatch is used:

    "handled" - the message was handled and not passed
    "unhandled" - no matching handlers were found
    "passed" - the message was handled but passed by all handlers

   In your example above, I suspect "it" contains "unhandled".

   Because dispatch offers this unique feedback to the caller,
   it rarely complains about things like "handler no found",
   instead noting that in "it".

   This is valuable for behaviors because behavior instances
   can individually override or overload handlers, so this
   not only gets the message to the desired target well but
   also provides additional information which may be useful
   to the behavior script that dispatched it.


This has been a long thread so I may have missed a few things, but I 
think these four rules cover just about everything I can recall from 
these explorations.

Have I missed anything?


Extra bonus point rule:  Anytime you you miss something from HC, ask 
here and Sarah or Jacque or me or someone else will help you find a way 
to do the same thing in Rev, and usually in the same number of lines or 
fewer. :)

I know that's a tall order, and with multi-card label printing HC will 
win because they provided a GUI for that.  But for just about everything 
else I can think of, Rev has shown itself to be very capable and 
remarkably efficient.

--
  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