>I can see where this might get sticky. Why would you want to make btn
>"defaultButton" the owner or parent of the new button. Couldn't you just
>pass on
>to the new button the same properties as the defaultbutton?
Raymond,
just that we agree on this: I don't want the basePart to be the "owner" of
its child in current HyperTalk terminology. That is, in my example the
following would result in a "part not found" error:
cd btn 5 of (the basePart of cd btn 5)
The "owner" or "of" relationship is separate from the basePart
relationship. BasePart works on handlers and properties, while "of" works
on the _containment_ hierarchy.
>I can see the advantages of having an extra layer of scripting, but this
>can be
>easily done, simply by "grouping" a single object. The group is the parent
>layer,
>and the object is the child.
But you can't group several buttons from different cards or stacks in the
same group object.
>THIS is the really tricky part. Since the basePart is not in the stack of the
>btn, but in the template stack, you will have a real problem if your template
>stack is ever separated from the stack you are working on. The only way I
>can see
>around this is if the template stack is actually the mainStack and the
>stack in
>which the child resides is a substack. Think of the standalones that wouldn't
>work. Oh, the agony! ; )
The template stack and the "current" stack could both be substacks of the
same mainStack. If you try to remove a stack which contains some other
stack's basePart you'd get an error message to dissociate (dis-associate?)
the two buttons before removing the stack. Since a basePart has to have a
list of all parts based on it to update them when it changes and the parts
based on it need to know their basePart so they can be modeled from it this
wouldn't even require opening another stack (for the engine).
>Of course, if you made the template an importable resource, it might work. But
>things could still get sticky. Consider this scene. You create a child object
>>from a template, realize that it is not doing exactly what you want, so
>>you go to
>the parent object in the template and make a change -- only to realize
>that you
>have changed every other child object that came from that parent!
That's why I suggest putting all of them in a separate stack. But of
course, this isn't enforced. Anyway, this is not really an issue, as this
is one of the reasons a class is intended for: to have many objects all
modeled after one "base class" and not to have to change several other
places when you want to change some common characteristic. And anyhow, it's
the same with icons today: if I change an image some button uses as its
icon this button's icon changes, too.
Of course, it would be nice to have a confirmation message popping up
whenever a part other parts are based on is modified (better make that the
first time, or it gets annoying). And of course, this should be reflected
somewhere in the part inspector window.
>If classes and
>inheritance were to be an issue, then I would rather like to see classes
>implemented similar to groups or backgrounds, but with the provision that they
>would not have to all be visible or used at once. You could edit the class
>object
>by going to it in the same way that you edit a background. The objects in the
>class could be seen residing there -- probably a list, with other properties
>viewable (card, stack, physical position, etc.).
If you put them in another substack your user never sees them. It seems
like a kludge at first, but if you consider it closely, it is more
powerful, since when you really need to, you can use this to create
interdependencies between objects very easily. Imagine a stack where you
have a card on which a graphic can be edited using paint tools. On another
card you want a preview of how the painting will look in a certain frame.
You can simply create a transparent button with this image as an icon. Cool
:-)
>The message hierarchy should go
>something like this:
>
>object -> object's class -> object's group -> card -> other backgrounds on
>card
>- -> stack -> mainstack.
>
>Did I get the rest of the inheritance issues correct? If we implement class
>structures, the class properties and scripts should probably come after the
>object's scripts, but before anything else.
Good to see we agree on this.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
