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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
