DunbarX wrote:
But there is still that mystery about "send". I use "send" all the time. And "dispatch" doesn't work, either. Anyone else concerned?

When I tested here, "send" complained with an error message, but "dispatch" worked fine.

That is, "fine" in the sense that the message was sent to the appropriate destination.

Whether it works as it should may be subjective. Seems to me that trapping the even should prevent the event's normal behavior, so to me it seems to work as expected.

If your stack has a handler to deal with the message all is good, you can handle it however you like.

But if the stack has no handler that you've told it to handle, the engine will complain.

This may differ from HC; can't say for sure, it's been more than half a decade since I booted a machine that could run it.

But I find in most cases where message behaviors differ from HC it's because Scott Raney is a speed freak. Not in the methamphetamine sense, but in the engine performance sense:

Early on he discovered that he could get many times greater performance by carefully pruning the message handling down to the essentials.

For example, you can't write your own custom definition for a built-in function like you could in HC, because by trimming built-in function names out of the search tree for script handling he was able to cut a lot of time out of that lookup.

I once argued with him on that one, insisting it was absolutely necessary to have it after I discovered it while doing a port. His answer was that if I need a custom behavior then use a custom name. He did offer to reconsider if I could come up with a scenario in which it would be truly necessary, but even after enlisting the help of the good folks here none of us could come up with one. So the speed boost remains, at the modest expense of an unnecessary convenience from another dialect.

Similarly, the mouseWithin handler is only sent in Rev when a control actually has a handler in its script for that; otherwise the engine doesn't bother sending it at all, saving a few hundred messages every second.

There are a few other cases where you'll see this at play, and perhaps that's what you found here: if the stack isn't handling the message, it isn't in the message lookup table and will generate a complaint.

As you've found, there are several alternatives available for your specific case, and in terms of performance the one you're using now (keyUp) will yield perhaps the best performance for you, certainly faster than the overhead involved with the dynamic compilation routines invoked with "send" (as with "do" and "value" too, though oddly enough "dispatch" benchmarks at least 30% faster than "send").

There seems to be a very different philosophy at play between Kamins/Winkler and Raney: K/W seem to favor flexibility, performance be damned, while Raney, with a degree in compiler design, favored performance over anything that could be reasonably done by other means that don't impair performance.

--
 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
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to