OOP in Rev...
ambassador at fourthworld.com
Wed Mar 19 10:59:17 EDT 2008
Len Morgan wrote:
> Putting the OOP vs rOOP discussion aside for a moment, I would love to
> have the ability to create "new" GUI objects. For example, consider a
> fader for a mixing board.
> It has a sliding "thumb" (like a scrollbar), usually a pan control at
> the top, perhaps a VU meter next to the slider to show the signal (sort
> of a progress bar), and a couple of text fields at the bottom for the
> name of the channel (Guitar, Vocal, etc), and the current dB value of
> the slider. Such an object would have properties for current slider
> position, set the VU meter level, set the pan position, etc. I'd like
> to be able to create this object and place it on a card just like a
> button or field.
> I suppose this could be done with a group (just about all of the
> required pieces are there and could be manipulated with xTalk) but I
> don't know of an easy way to store that "object" in such a way that I
> could drop it on to a card. Perhaps a future enhancement might be
> "stack format" that could save just an object in it (.obj or .wid?). I
> don't think that would be too big a stretch.
> Any ideas or comments?
You could make a substack called "ObjectTemplates" and store your custom
group widgets there. To get them on the current card, just use:
copy grp "MyWidget" of stack "ObjectTemplates" to this cd
The nice thing about that form of the copy command is that when you
specify a destination the object goes directly there rather than to the
clipboard, so the user's clipboard data is not affected.
If you need a simpler form you could write a handler like this:
on CreateCustom pObjectType
copy grp pObjectType of stack "ObjectTemplates" to this cd
...so when calling it you never need to remember where the template
group object is locatated:
Ken and I have adopted a convention over the years of defining custom
object types in a library, putting as little code as possible into the
widget itself and instead having its UI elements call handlers in that
library. This allows us to fix bugs and provide enhanced behaviors by
working with just one script, and all instances of the object reflect
The Rev Interoperability Project has produced a set of guidelines for
making libraries and custom widgets which can be shared with others more
easily by storing common metadata (type, copyright, version, etc.) in a
set of custom props -- see the ECMI Spec (Edinburgh Core Metadata
Initiative) in the Files section here:
For example, using the uRIP["type"] property, a frontScript or library
can easily identify the type of control, so system messages can be
routed to specific handlers if needed, using simple in-the-path
messaging rather than the slower send command:
if the uRIP["type"] of the target is "Splitter" then
ufwSplitterMouseDown -- defined in a library
else pass mouseDown
We've had more than a dozen Rev developer contribute to the ECMI
guideliness, and at this point they're complete enough that it's
possible to make version control and auto-update tools that work on all
ECMI-savvy components regardless of who made them. There are tools
there now ("RIPEdit" and others) which make it easy to add RIP
properties to a stack with a simple inspector tool.
One downside to working with groups as custom controls is that they're
inherently brittle during development; that is, it's really easy to turn
on the selectGroupControls and accidentally move controls within the group.
This RQQC request addresses this by proposing a new "locked" property
for groups which would make them behave as a single control under the
pointer tool, regardless of the state of the selectGroupControls global
Managing Editor, revJournal
Rev tips, tutorials and more: http://www.revJournal.com
More information about the use-livecode