Hi Mark,
I looked at your example and the ISM stack I have developed is *VERY*
similar to your mc2_libDispatcher. The only main difference I can see
is that I have a secondary Message/Event ID which I call a "Kind".
This is to allow you to have more than one copy of the same event.
There is also a difference in the way in which your example actually
uses the Dispatcher, you do your "Listening" or "Registering" at the
Stack level, which means you have to change the Stack Script when you
add a control to the stack:
On 27 Mar 2006, at 07:08, Mark Wieder wrote:
on openStack
start using stack "libDispatcher"
mc2_libDispatcher.Register the id of field "FileContents", \
"NewFile", the id of field "FolderContents"
mc2_libDispatcher.Register the id of field "FolderContents", \
"NewFolder", the id of button "Choose"
end openStack
This means you are hardcoding control names into the stack. I *could*
do it this way too, but in order to allow objects to be pasted and
duped in a stack and have them just work without changing any other
scripts, I do the "Register" at the control level.
Other than that the concepts are identical!
As I've explained, I don't bypass or in any way effect the existing
message-passing hierarchy. ISM works *with* the xTalk environment.
Thanks for your input.
All the Best
Dave
_______________________________________________
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
