Target not working???

[David Burgun]

Hi Mark,

On 27 Mar 2006, at 22:41, Mark Wieder wrote:

> David-
>
> Monday, March 27, 2006, 9:21:13 AM, you wrote:
>
>> All I want to do is to call a handler if it exists in a script. I've
>> read up on the message path etc. but not sure how it applies in this
>> case. Could you elaborate?
>
> OK. Now I see what you're trying to do here. But I still see two
> problems with this:
>
> One, I don't see a way to differentiate messages coming from multiple
> sources. If object A responds to B events, then how do you limit it to
> responding only to B event messages from object C? What if object D
> also generates B events?

That's legal. A message is sent  to *all* listening objects. For  
example, a "Folder_Selected" message could be sent to a field that  
displays the folder path name, another that uses the folder path name  
to display a list of files, another field that just displays the  
folder name without the path and a button that is enabled or disabled  
depending on if there is currently a folder selected.

If you want to have more than one folder, e.g. say a source and  
destination folder, then you can use the "Kind" field to  
differentiate, e.g. objects that want to act on a Source folder being  
selected  listen for  "Folder_Selected", "FolderKindSource" and  
objects that want to act on the Destination folder listen for   
"Folder_Selected", "FolderKindDestination".

> Two, I still think you're fighting the "natural" object hierarchy. Why
> not have the stack initialize its own objects when it starts up
> instead of forcing it from the parent stack? Or more correctly, why
> not have the library stack tell each of its controls to initialize
> themselves, i.e.,
>
> -- in the library stack
> -- untested code
> on openStack
>   local x
>
>   repeat with x=1 to the number of controls of this stack
>     try
>       send "ISM_InitializeObject" to control x
>     end try
>   end repeat
> end openStack
>
> on closeStack
>   --unregister all objects
> end closeStack
>
> Or, if you use setProp handlers instead, you can just say
>
> on openStack
>   local x
>
>   repeat with x=1 to the number of controls of this stack
>     set the ISM_InitializeObject of control x to empty
>   end repeat
> end openStack
>
> then you don't have to worry about whether or not the control supports
> the ISM_InitializeObject handler - you'll just set a harmless custom
> property if it doesn't.
>

There are a number of reasons:

1.  I am trying to cut down on the amount of code and the number of  
places that needs to be changed if you want to either add an existing  
object from the Object Library or to write a new Object (that might  
be added to the library at a later date).

2. Speed. I do more than just send the ISM_InitializeObject message  
while looping thru the objects in a stack. At present there are  
checks on a call-by-call basis (e.g. when a stack Calls a  
"ISMListenForMessage" or "ISMPutMessage")  and this impacts the  
performance. It's better to do all this at "start using" time and  
hold that information so as to save time once ISM has initialized.  
This is a data dependent algorithm (which are to be avoided if  
possible) and I am just following good software engineering practice,  
e.g. if you absolutely MUST use a data dependent algorithm the put as  
much processing as possible so as to make it more worthwhile.

3. Although the code I posted shows the ISM_InitializeObject being  
called in the loop, this was just to illustrate what I wanted to  
achieve. In the real Library I actually just build a list/array and  
call the handler later on.

4. It seems like better OOP practice to hold all the information/code  
that an object needs in one place.

I really can't see that I am "fighting the "natural" object  
hierarchy". The loop (or something like it needs) to be held  
somewhere, the fact that it is held in a "central" place really  
doesn't make much difference. In your example I'd need N loops, one  
for each stack, doing it my way just results in one loop, e.g. less  
code. Of course you could make a common function out of your loop and  
store it in the Stack Script or in a Library and then just call it  
from each object. This wouldn't be "fighting the "natural" object  
hierarchy", so how can putting in *my* library be different?

All the Best
Dave