Component Model

[Karl Petersen]

At 11:42 PM -0700 7/7/02, Dan Shafer wrote:
>Does RR have a true component model? One that would allow me, e.g., 
>to create a new *type* of component either by aggregating existing 
>ones or by starting with an existing component, changing default 
>properties and then saving it in a way that I could transparently 
>use it in my RR apps?

Dan, check out the Object Library in the Development menu. It allows 
you to install Rev-defined objects that ship in the Library, plus 
install your own objects you've added to the Library. You can also 
create new libraries you access via the Object Library.

It that's not exactly what you need, it's not difficult to create 
your own custom object library that uses your own installer scripts. 
Your script can refuse to install a field unless a group is selected 
as its destination, for example.

Remember too that like HyperCard, Rev sends a new<Object> message to 
a new object when it is created. (NewField, newButton, newImage, et. 
al.) That lets you create very smart objects that can help install 
themselves. They can even create/configure other objects around them.

Like you, I wanted a special field I could quickly install in new 
stacks. I wanted it to know how to resize itself when the window size 
changed and modify the appearance of its scrollbars when the stack is 
suspended/resumed. (The field covers its scrollbars with buttons so 
they look "disabled" like normal Mac OS scrollbars.) Responding to 
the newField message it receives, the field creates the scrollbar 
cover buttons it needs, saves their button IDs in a field property, 
and installs a group script that broadcasts 
resizeStack/suspend/resume messages to all objects in the group. When 
done, the field also removes its own newField handlers.

A running field script can't perform certain tasks --  modify its own 
script, for example -- but that can be accomplished by "sending" a 
message to a group owner for execution a few milliseconds after the 
field is installed.

Rev's custom properties are extremely useful here too. A property of 
the field stores the group script, for example. When the field is 
finished installing itself, it deletes all the custom properties it 
no longer needs.

Note that the new<Object> message is NOT sent when you Paste an 
object, so Copying and Pasting is limited to simpler objects. But 
beyond that limitation, just about anything is possible.

Karl