Geometry in latest version of RunRev

[Richard Gaskin]

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