Dave -
On 1 Nov 2007, at 15:07, Richard Gaskin wrote:
That may not be merely a limitation of the GM, but possibly a bug.
Did you report it? It'd be interesting to run the sample stack
submitted with the report to find how it could be repaired.
I missed your reply to this. If you have the BZ report # handy I'd be
happy to post a verification to help expedite the fix.
The resizeStack message is sent to the card, not the controls on
the card. So how do these controls get notification to update
themselve without something referring to them without using one of
the three ways to refer to objects?
Well, in this case the resizeStack message in the Card Script would
send a "xxxResizeStack" message and any object listening for this
message would get called. The calling handler would then resize
itself using "me". No reference explicit reference to an object,
therefore any object can be cut and pasted anywhere are they will
still work and the place where they were removed from won't break.
I developed a Library ages ago I call ISM. It allows objects to
"listen" for messages on a certain key and another object to send
message to this "key" and have all "listening" objects receive the
message.
For me, it's the only way to develop modular objects that I can more
around at will with no or little backwork.
Interesting approach. I use a similar "listener" method for data
binding, but for non-data controls I just use the native message path.
But if you're getting the productivity you're after, more power to you.
Good job.
And in such a case, how would the object whose position is
dependent on another know the other object's position without
referring to it?
The handler in the current object would refer to "me" and would
receive messages telling it where the other objects it has to worry
about are located and how to position itself relative to them.
Doing it this way makes life a LOT easier!
...provided this system has some means of ensuring the order in which
messages are sent.
Do you flag the properties driving this in a way that maintains a
predictable firing order? The firing order seems to be the weak part of
the GM, and with complex interdependencies among object positions it can
be daunting with a property-driven approach. Not impossible, but in
addition to the other data it would also need to store an ordinal
reference of some sort, since property array elements are not inherently
ordered and of course object order is always subject to change.
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: http://www.revJournal.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
