Len Morgan wrote:
Phil,
We may need to get a ruling from the judges on this one! After seeing
the statement you quoted in isolation, it seems it could be possible
to have a button who's mouseUp handler calls a handler in a library
stack that has the actual accept command. In that case, the button is
the target but the library stack actually contains the accept command.
That's the Rev message path in action. In the case you describe, I'm not
sure where the callback handler would have to be; but in my world I
would probably put it in the same library script that contains the
handler with the "accept" command.
Your idea of putting the accept further down in the message path is
what I wanted to do but the documentation seemed to indicate this was
not possible.
Try it, my friend! The worst that can happen is that it won't work.
Can we get a ruling and clarification of the docs on this point from
some of the more experienced members with socket experience?
len
A simple test should give the desired clarification. Then you can be the
expert! ;-)
FWIW, I once implemented a sockets interface to a special hardware
device as a Rev library that goes in and out of use depending on user
choices. That's my biggest sockets exploit.
Since the message path is such a fundamental part of the Rev world, I
would think the Rev docs would say something if a command or function
DOESN'T work with the message path as expected. But I'm not aware of any
such instances.
Phil
Phil Davis wrote:
[email protected] wrote:
Actually, I think the opposite is true: If the callback script is
NOT in
the button script, it won't ever fire. At least that's the way I
read the
docs.
My bad - you're right. That was my habit speaking. ;-) I habitually
place callback handlers further down the message path from the object
whose script opened the connection. But the docs say:
The callbackMessage is sent to the object whose script contains the
accept command.
Thanks -
Phil Davis
_______________________________________________
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
