I really don't think you understand the ISM concept and think it's
some strange thing that is somehow going against the way Xtalk's
work. It's really not. It's really just a convenient and flexible way
of allowing an object to communicate with other objects without
having to explicitly tell the objects what do do.
Think of it like this. You could write some code that did the following:
put "[EMAIL PROTECTED]" into field "EmailAddress"
enable button "OK"
disable field "PhoneNumber"
etc.
In (say) a mouse up handler of a "Do Some Action" button. In other
words the logic to determine what to do to other objects is
determined by the object that initiated the event. This means that
when you want a different action for an existing object or additional
actions or actions for other objects you have to change the "sender".
It's like a teacher in a class room telling each individual pupil to
turn to page 66 of a text book, instead of telling the whole class.
This isn't the best example, since, the *same* action is performed by
each pupil in the class. Instead, imagine you said, "Go to the page
where you left off last week and continue from that point". The
difference is that you could either track which page each individual
pupil is on and give out many instructions such as "John, go to page
33", "Bob, go to page 54", "Julie, go to page 132" or could leave the
decision as to which page to go to up to the person receiving the
instruction and give one instruction and they could use their memory
to go to the correct place. ISM allows you do do this.
For instance, with a file path name, different fields may want to do
different things:
Field 1 - put theFilePathName into field 1
Field 2 - put <the_contents> of file theFilePathName into field 2
Using ISM, you put the choice of what to do with the data received in
the Object that is processing the data. not in the sender of the data.
This is basic OOP.
All the Best
Dave
Hi,
All my messages pass along the very same chain you are using, the
fact that there is a library that is managing events has nothing to
do with it. I've experienced the problems I mentioned (and they have
been verified by others) in small 3 control test stacks with no
libraries etc. I do not "force" anything into a central object
library or any other kind of library.
All the Best
Dave
On 7 Apr 2006, at 17:32, Rob Cozens wrote:
David, et al:
In the case of the bugs I mentioned, you'd have to blind and in a
drug induced haze not to spot them! Some of them occur on an
hourly basis!
For the past two weeks I have been scripting at least four hours
daily using Rev v2.7 on Windows XP.
I have experienced no crashes--even when trying to force a crash
for Rev Support. I don't spot the bugs you mention because (a) I'm
not using the same features your are, and (possibly) (b) because I
allow most messages to pass up the message chain rather than trying
to force them to a centralized object library.
This is not said to discredit you; but to point out that RunRev is
so feature-rich and can be applied to such different applications
that one developer's experience may be entirely different from
another's.
Rob Cozens
CCW, Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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
