Re: widget layout [message #31546 is a reply to message #31431] |
Tue, 16 July 2002 12:22   |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Ted Cary (tedcary@yahoo.com) writes:
> Actually, I was thinking of implementing something like your object
> container widget hierarchy specifically for my resizer helper object,
> although it seemed like a lot of work for just this this routine.
I can tell you that wrapping widgets up in objects is
a hell of a lot of work! :-)
Although, to be fair, you only have to do it once. But
there are more decisions to be made then you would have
initially thought, and there is a lot of hemming and hawing
about where keywords should be implemented, etc. We have
opted for a subset of functionality rather than trying for
absolutely everything possible.
But this automatic resizing of widgets is attractive to
us because it seems relatively simple to implement with
our current object structure.
> The way the resizer is supposed to work is by searching a widget hierarchy
> and finding all the resizable widgets in the TLB--by default, draw widgets.
This is quite easy in an object containment hierarchy, because
a GET method can easily find an object of any "type" included in
the container.
> It resizes their windows around the other non-resizable realized widgets,
> whose dimensions remain fixed. The resizing depends upon the layout of the
> draw widgets in a base, which is why I needed to know this information.
> For example, if a TLB with three draw widgets in a column is resized, the
> default behavior is to distribute the change in base height evenly among the
> three draw windows. Sizing of TLBs with menubars is handled automatically,
> and there are options to fix individual draw widget window dimensions as
> well as to set maximum and minimum dimensions.
The object widget INIT method knows exactly how baseWidget objects are
laid out, so setting up the "resizer" portion of the widget object
should be trivial. A simple keyword could mark the widget object as
potentially "resizeable".
> The problem with the routine is the "searching the widget hierarchy" part,
> since to be completely general it needs to find all resizable widgets and
> treat them differently according to the layouts of their bases.
A "resize" request could simply bubble down the containment hierarchy,
with each object passing the message on to its children, who could
respond or not, depending upon their internal resize information. The
message could become increasingly detailed as it travels down the
hierarchy, so that a widget would know exactly what it was suppose to
do.
> But aren't the widget hierarchies in IDL essentially stored
> internally as object trees anyway? If only there were just a WIDGET_WHERE
> function and a truly comprehensive WIDGET_GET_PROPERTY....
In our system, GetProperty requests can bubble up to parent containers
if they can't be fulfilled by the object who is initially requested to
supply the information. I think that is what you mean here. It is a
powerful concept.
(I'm always a bit confused if we are bubbling "up" or "down". This
is one of the reasons I haven't written an object book yet. I'm sure
to get a great deal of criticism for the way I think about these things.
I think [but am not absolutely sure] that I am internally consistent,
anyway. Sigh...)
> Anyway, what I can show you now is how the individual TLB resizer node
> works. If you already have the widget tree structure, maybe it's all you
> need, and probably you can improve upon it. In fact, the TLB node works
> fine for my typical application--some draw widgets in a TLB, resized around
> some labels and buttons, etc.... I'll remove the "print" and "help"
> statements and add some comments first, so give me a few days.
I look forward to seeing 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
|
|
|