| Re: Tip for using Compound Widgets [message #31682] |
Mon, 05 August 2002 19:04  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
M. Katz writes:
> Since I'm over 30, I'm still getting used to object programming. I'm
> using it all the time for creating complicated graphics and even for
> the file-output tasks, but it's still "new" to me.
Over 30!? I can only imagine. :-)
> The idea of the compound widget is that we create something new that
> behaves like one of the basic elemental widgets. I can see making the
> leap to objects in several ways, and I'm interested to hear how you'd
> recommend doing it. (Have you written any tips for it on your site?)
Have a look a FSC_FIELD. That is a compound widget that is written
as an object.
http://www.dfanning.com/programs/fsc_field.pro
> When using a compound widget, one accesses the child widgets through
> the parent. That includes events and SET/GET_VALUE. That's the issue I
> was trying to solve: making SET_VALUE more intelligently access the
> functions of the compund widget.
>
> So, in an object widget, (here's where I'm guessing) one doesn't need
> the compound widget formalism. You create an object that knows all
> about the children and dispense completely with
>
> widget_control, SET_VALUE=... in favor of
> widget_obj -> Do_Something, arg
That is right, exactly!
> But what exactly happens to events?
I have an "event handler" for the compound widget (same as in
widgets), but any widget that generates events has a structure
in its UVALUE that has an "object" field and a "method" field.
For example, here is a quit button (in another program, not
FSC_FIELD):
button = Widget_Button(bbase, Value='Quit', $
UVALUE={object:self, method:'Quit'})
All the event handler does is get the user value and dispatch the
event to this method of this object:
PRO EVENTHANDLER, event
Widget_Control, event.id, Get_UValue=cmd
Call_Method, cmd.object, cmd.method, event
END
I use the EVENTHANDLER to handle *all* object widget events.
The objects and methods vary, of course. The methods are written
*exactly* like previous event handler procedures, except they
don't have to have the info structure, since the info structure
*is* the object!
> Does it take a lot longer to program the object widget than the
> equivalanet compound widget?
No, about the same amount of time.
> Is there a template that's been published that other people follow, so
> object newbies don't have to re-invent the wheel? Does RSI have
> anything to say about the subject, as they do for compound widgets?
I don't know if RSI has anything to say about the subject.
Some of those guys write nice object code, however. I've
learned a lot by studying it. :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-Mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: Tip for using Compound Widgets [message #31686 is a reply to message #31682] |
Mon, 05 August 2002 13:36  |
Pavel A. Romashkin
Messages: 531
Registered: November 2000
|
Senior Member |
|
|
In addition to David's rightful remark, I'd like to add that although I
fully admit that OW is the way to go, you could still explore the
classic Wid environment.
Now, here's the challenge.
Can you make your method generic enough so that you do not have to write
separate sections in your event handler, but use your library procedures instead?
I think this will be more powerful because then the event handler is
much more streamlined, and, secondly, you can pass all sorts of other
parameters via your structure interface.
Hint: simply use CALL_FUNCTION or PROCEDURE and pass the parameter
structure using keyword inheritance :-)
Good luck,
Pavel
"M. Katz" wrote:
>
> I do a lot of widget programming in IDL, and I've recently come across
> an elegant solution I'd like to share. Others have probably already
> thought of this, or may have a better idea, so I hope I'll start a
> dialog.
|
|
|
|
| Re: Tip for using Compound Widgets [message #31705 is a reply to message #31686] |
Sun, 04 August 2002 12:43 |
MKatz843
Messages: 98
Registered: March 2002
|
Member |
|
|
David Fanning <david@dfanning.com> wrote in message
>> I'd be interested to know if anyone else uses tricks like this, or has
>> a better way,
>
> Oh my goodness, Mr. Katz. You are so very, very close
> to writing object widgets.
Since I'm over 30, I'm still getting used to object programming. I'm
using it all the time for creating complicated graphics and even for
the file-output tasks, but it's still "new" to me.
The idea of the compound widget is that we create something new that
behaves like one of the basic elemental widgets. I can see making the
leap to objects in several ways, and I'm interested to hear how you'd
recommend doing it. (Have you written any tips for it on your site?)
When using a compound widget, one accesses the child widgets through
the parent. That includes events and SET/GET_VALUE. That's the issue I
was trying to solve: making SET_VALUE more intelligently access the
functions of the compund widget.
So, in an object widget, (here's where I'm guessing) one doesn't need
the compound widget formalism. You create an object that knows all
about the children and dispense completely with
widget_control, SET_VALUE=... in favor of
widget_obj -> Do_Something, arg
But what exactly happens to events?
Does it take a lot longer to program the object widget than the
equivalanet compound widget?
Is there a template that's been published that other people follow, so
object newbies don't have to re-invent the wheel? Does RSI have
anything to say about the subject, as they do for compound widgets?
Thanks for your advice!
M. Katz
|
|
|
|
|
|
| Re: Tip for using Compound Widgets [message #31946 is a reply to message #31682] |
Thu, 29 August 2002 10:13 |
Rob.Preece
Messages: 8
Registered: December 1999
|
Junior Member |
|
|
In article <MPG.17b8dc785d0409dc98994f@news.frii.com>, David Fanning
<david@dfanning.com> wrote:
>
> I have an "event handler" for the compound widget (same as in
> widgets), but any widget that generates events has a structure
> in its UVALUE that has an "object" field and a "method" field.
> For example, here is a quit button (in another program, not
> FSC_FIELD):
>
> button = Widget_Button(bbase, Value='Quit', $
> UVALUE={object:self, method:'Quit'})
>
> All the event handler does is get the user value and dispatch the
> event to this method of this object:
>
> PRO EVENTHANDLER, event
> Widget_Control, event.id, Get_UValue=cmd
> Call_Method, cmd.object, cmd.method, event
> END
>
Good grief! You are *this* close to creating a 'command macro' language
for your widget objects (something I have been thinking about for some
time, I might add!). All that is needed is a way to store lists of
commands, so that they could be replayed at any time. It would be nice to
edit, store and recall these lists. Finally, think about a *recordable*
widget program: hit a button, and the following user actions are saved as
a list of commands, to be available for later replay...
> I use the EVENTHANDLER to handle *all* object widget events.
> The objects and methods vary, of course. The methods are written
> *exactly* like previous event handler procedures, except they
> don't have to have the info structure, since the info structure
> *is* the object!
>
Hmm. You have a global commmand dispatch object then? I like it even
better. I suppose that positional parameters for the methods are contained
in the event structure passed to CALL_METHOD...
- Rob
(P.S. to David: I blew through Bolder on my family trip to Utah earlier in
the summer. We arrived *way* too late to look you up for a Fat Tire ale,
so I owe you one.)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
