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