OOP in Rev...

[Richard Gaskin]

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
  end CreateCustom

...so when calling it you never need to remember where the template 
group object is locatated:

  CreateCustom "MyWidget"

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 changes.


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:
<http://tech.groups.yahoo.com/group/revInterop/>

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:

   on mouseDown
     if the uRIP["type"] of the target is "Splitter" then
         ufwSplitterMouseDown  -- defined in a library
     else pass mouseDown
   end 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 
property:

<http://quality.runrev.com/qacenter/show_bug.cgi?id=2144>


-- 
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com