[Ticket#: 2006040510000641] Re: [OT] Articles to read

David Burgun dburgun at dsl.pipex.com
Sat Apr 8 08:00:34 EDT 2006


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

_______________________________________________
use-revolution mailing list
use-revolution at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your  
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution



More information about the use-livecode mailing list