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
_______________________________________________
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
