Hi,
I think we are talking about two similar things here and they are
getting muddled!
1. Developing new controls and code to control them.
2. Re-using Existing Controls or Groups of Controls that are stored
in an "ObjectLibrary" (which is really just a "Dummy" stack that is
used to store the objects).
For point 1, you have to write new code regardless of the method
employed. Whether it's in one location or spread over a few different
objects make no real odds. The Code to solve the problem will be
roughly the same. The main difference is that using ISM I can then
make the new Group/Control available via the "ObjectLibrary" and it
will work with any existing objects in the library.
For point 2, I can just drop a number of objects/groups from the
Object Library into a new stack and they will interact with each
other without changing *anything*, *anywhere*. Also if I want the
same group/object twice, then I just paste it twice and change the
Custom Property that specifies the "kind" of message. This means of
course that code in a control may be duplicated in another control.
However, this is nothing stopping you having a "common" function
defined in the Group that can be called from all the controls within
that group, I do this a lot. Also there is nothing stopping you
"listening" at the group level, then the Message will be sent to the
Group and it can do what it needs to do to the objects "below" it, in
the same way as having a "mouseUp" handler in the group and using
"target". In fact "target" still works and returns the target of the
control that caused the event (e.g ControlX:mouseUp->ISMPutMessage-
>GroupY:MessageHanlder returns the target "ControlX". The fact that
the message was delivered via ISM doesn't matter). Similarly Groups/
Controls can do a "start using" and get access to all routines
defined in a Library Stack. I haven't tried it but I can't see any
reason why Front/Back Scripts wouldn't work either. So ISM isn't
ignoring the xTalk environment it's just making it easier to re-use
objects and it's ensuring that only objects that need to have an
action taken are visited.
In a similar manner you can also "listen" at the card or stack level
or have "common" functions at the Card or Stack Level.
It also aids in documentation since you can easily do something like
this (which I am in the process or doing):
Name: Group_Select_Folder
Purpose: Allows the User to choose a folder and
broadcasts the folder to all listening objects.
Message Sent: msg_FolderSelected, sends cpFolderKind and the
Path Name of the Folder selected.
Custom Properties: cpFolderKind, defaulted to "FolderKindX", change
if you wish to send a different folder kind.
Message Handled: None.
Comments:
Name: Group_File_List
Purpose: Displays a List of Files in a Specified
Folder, allows the user to select a file and broadcasts the file to
all listening objects.
Message Sent: msg_FileSelected, sends cpFileKind and the
Path Name of the File selected.
Custom Properties: cpFolderKind, defaulted to "FolderKindX", change
if you wish to receive a different folder kind.
cpFileKind, defaulted to
"FileKindX", change if you wish to send a different file kind.
Message Handled: msg_FolderSelected.
Comments:
It makes debugging easier too. I have some functions in ISM that
switch on/off Debug mode. With Debugging enabled, ISM will dump
information into a field or file and you can then trace the messages
being sent and which handlers are being called, along with the
message data. There are also filters that work in a similar (but more
specialized) way to the Message Watcher in the IDE. It also dumps the
time in the message handler so you can see how long a particular
message takes to process.
No, there is no hard-coding of object names in the script anywhere.
That is always a bad idea and always to be avoided. And the script
example I posted deals transparently with new objects, deleted
objects, and existing objects. You don't have to do anything.
Ok, then you have to scan all objects.
As for visiting each object, this isn't much of an issue given
Revolution's engine speed; I have successfully updated thousands of
objects in a preopenstack handler in only a few ticks. With your
method, there must be some way for the "listening" objects to know
they are supposed to listen.
I keep a number of Arrays which are fast. There is some overhead in
the "send" command but I've found it is faster then visiting all
objects especially when dealing with multiple stacks.
The only way you can do that without scanning all objects in the
stack is to keep a list somewhere of which objects need to be
triggered, and use "send" to send an instruction to each object in
the list in order to trigger that response. The "send" command has
a high overhead; I'd guess that with a long list of objects to
trigger your method could take as much time or longer than a simple
repeat scan. Another disadvantage to keeping such a list is that
you have yet another detail to maintain in your setup.
I really can't see this! Say you had 100 objects but only 10 needed
to be updated. The code to do the updating would be roughly the same
in either case, so we are only talking about 10 additional "sends" as
the overhead. I can't see that running a repeat loop for 90
additional objects is faster than doing 10 sends.
Surely the only time scanning all objects would be faster in this
case is if the number of objects needing "action" at a given time is
near to the total number of objects, the worse case being if all 100
needed action. In this case my method would incur the time taken to
do 100 sends, however the actual processing time needed to perform
the action(s) is likely to be large in this case and the overhead of
one additional send per object would be a small percentage of the
total processing time.
If we now change the total number of objects to 1000, but only 10
needed to be updated then you are visiting 990 additional objects!
The real point here is that using your method you can't tell in
general how much overhead an update for a particular action will
take, it will depend on the total number of objects, e.g. the
algorithm is data dependent and will slow down as the number of
objects grows. Whereas my method I can calculate the overhead exactly
and that overhead will be in direct proportion to the number of
objects needing attention as a result of an event.
According to Richard Gaskin a Send operation has an overhead of
0.011 ms. So for 100 objects we are talking about 1.1 thousandths of
a second and for 1000, 11 thousandths of a second and that's only if
*ALL* the objects needed attention. I doubt if a user would even
notice this!
This is one thing that was drilled into me as a youth when I first
started programming - "Data dependent algorithms should be avoided
wherever possible".
I'll snip the rest; I really didn't mean to start an argument. And
I get the feeling that neither of us really understands the other's
method, so I probably shouldn't keep talking. I only wanted to
point out to those who may still be following this that your method
adds some overhead and a degree of complexity that isn't necessary,
and it ignores the native message path and object inheritance that
Revolution depends on for efficiency. Using Revolution's native
techniques, I believe, will be simpler and more productive. But if
you have found a way to do something you like, that's fine with me.
I certainly have no argument with that, and it is proof that Rev
can be used in so many ways that it can accomodate all styles and
scripting techniques. If you like how your method works, that's
great. Really, I don't have an disagreement with that.
See above, my method doesn't stop you from doing this.
I snipped the rest too, since I think the first few paragraphs
explain how we are talking at cross purposes here and hopefully
explains my method a little more clearly. You don't *need* to have a
script on *each* control, you can handle the message at a higher
level if you want to and it doesn't stop you from using any of the
features of the xTalk environment. There are differing levels of
control here:
Sigh. No, I'm not scared of "different" things. You've been using
xtalk for 2 years, I've been using it for 21 years. I have pretty
much figured out, I think, which methods work best. In my HyperCard
days, someone told me once that I wrote the most elegant and
efficient code they had ever seen. I don't usually toot my own
horn, but that was something that made me very proud. I have spent
quite a bit of time figuring out what works and I use those methods
in my professional work. But I have no "fear" of any experimental
method you choose to use. I probably won't use it myself, as it
doesn't seem to be the best use of the xtalk paradigm, but feel
free by all means.
I wasn't really aiming that remark at you personally or anyone on
this list. I was actually a bit hacked off with the attitude of
someone I work with who won't even look at anything unless it's coded
in C++! I had just gotton off the phone with him when I wrote it and
I suppose it bubbled over into this discussion. Please accept my
sincere apologies if I caused offense. You have been of great help to
me in on the list in the past and I would like to take this
opportunely to say "THANKS A LOT".
Take Care and 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
