How can a widget react to a parent's resize?

[Joe Sewell]

I'm writing a composite widget (actually a subclass of XmManager) that
should span the entire width of its parent, unless a resource in the
composite widget itself says otherwise.

The problem is at Initialize time. The parent is doing its initial
geometry negotiations, so its core.width resource is 0. This is
obviously the right answer (or at least not the wrong answer) since
it's trying to determine how wide it needs to be. By the time the
parent knows how wide it wants to be, though, its children (including
my widget) isn't allowed to change its size.

I really don't want to put a StructureNotify event handler on the
parent, and setting up a zero-time timeout or workproc isn't all that
favorable, either. So far, though, those are the only solutions I can
come up with. I *don't* want to depend on the parent doing the heavy
lifting (e.g., forcing the parent to be an XmForm with my widget's
XmNrightAttachment constraint set to XmATTACH_FORM), though that may
be the most palatable solution.

Any suggestions other than those?

[Fred]

Post by Joe Sewell
I'm writing a composite widget (actually a subclass of XmManager) that
should span the entire width of its parent, unless a resource in the
composite widget itself says otherwise.
The problem is at Initialize time. The parent is doing its initial
geometry negotiations, so its core.width resource is 0. This is
obviously the right answer (or at least not the wrong answer) since
it's trying to determine how wide it needs to be. By the time the
parent knows how wide it wants to be, though, its children (including
my widget) isn't allowed to change its size.
I really don't want to put a StructureNotify event handler on the
parent, and setting up a zero-time timeout or workproc isn't all that
favorable, either. So far, though, those are the only solutions I can
come up with. I *don't* want to depend on the parent doing the heavy
lifting (e.g., forcing the parent to be an XmForm with my widget's
XmNrightAttachment constraint set to XmATTACH_FORM), though that may
be the most palatable solution.
Any suggestions other than those?

You don't do size negotiations in your Initialize method. Here's what
you need:

1. Create a QueryGeometry method (core class part's query_geometry
field) that is
called by your parent when the parent wants to know your preferred
size.

2. In your ChangeManaged method (composite class part's
change_managed field)
that is invoked whenever a child of yours is managed or unmanaged, you
re-calculate
your desired size and call XtMakeResizeRequest to tell your parent you
want a
new size.

3. IN your Realize method (core class part's realize field), you do
the same as
#2 above.

4. In youyr GeometryManager method (composite class part's
geometry_manager
field), which is called when a child wants to change size, you also do
the same
as #2 above after re-determining your desired size.

--
Fred Kleinschmidt

[Joe Sewell]

Post by Fred

Post by Joe Sewell
I'm writing a composite widget (actually a subclass of XmManager) that
should span the entire width of its parent, unless a resource in the
composite widget itself says otherwise.
The problem is at Initialize time. The parent is doing its initial
geometry negotiations, so its core.width resource is 0. This is
obviously the right answer (or at least not the wrong answer) since
it's trying to determine how wide it needs to be. By the time the
parent knows how wide it wants to be, though, its children (including
my widget) isn't allowed to change its size.
I really don't want to put a StructureNotify event handler on the
parent, and setting up a zero-time timeout or workproc isn't all that
favorable, either. So far, though, those are the only solutions I can
come up with. I *don't* want to depend on the parent doing the heavy
lifting (e.g., forcing the parent to be an XmForm with my widget's
XmNrightAttachment constraint set to XmATTACH_FORM), though that may
be the most palatable solution.
Any suggestions other than those?

You don't do size negotiations in your Initialize method. Here's what
1. Create a QueryGeometry method (core class part's query_geometry
field) that is
called by your parent when the parent wants to know your preferred
size.
2. In your ChangeManaged method (composite class part's
change_managed  field)
that is invoked whenever a child of yours is managed or unmanaged, you
re-calculate
your desired size and call XtMakeResizeRequest to tell your parent you
want a
new size.
3. IN your Realize method (core class part's realize field), you do
the same as
#2 above.
4. In youyr GeometryManager method (composite class part's
geometry_manager
field), which is called when a child wants to change size, you also do
the same
as #2 above after re-determining your desired size.
--
Fred Kleinschmidt

I'm doing all this now (courtesy of Alestair Gourlay's XmpGeometry
widget, which I'm subclassing) ... well, *except* for the Realize
part. That's probably where I need to put it to catch the initial
size, with subsequent size changes of my widget's parent invoking
QueryGeometry.

[Joe Sewell]

Post by Fred

Post by Joe Sewell
I'm writing a composite widget (actually a subclass of XmManager) that
should span the entire width of its parent, unless a resource in the
composite widget itself says otherwise.
The problem is at Initialize time. The parent is doing its initial
geometry negotiations, so its core.width resource is 0. This is
obviously the right answer (or at least not the wrong answer) since
it's trying to determine how wide it needs to be. By the time the
parent knows how wide it wants to be, though, its children (including
my widget) isn't allowed to change its size.
I really don't want to put a StructureNotify event handler on the
parent, and setting up a zero-time timeout or workproc isn't all that
favorable, either. So far, though, those are the only solutions I can
come up with. I *don't* want to depend on the parent doing the heavy
lifting (e.g., forcing the parent to be an XmForm with my widget's
XmNrightAttachment constraint set to XmATTACH_FORM), though that may
be the most palatable solution.
Any suggestions other than those?

You don't do size negotiations in your Initialize method. Here's what
1. Create a QueryGeometry method (core class part's query_geometry
field) that is
called by your parent when the parent wants to know your preferred
size.
2. In your ChangeManaged method (composite class part's
change_managed  field)
that is invoked whenever a child of yours is managed or unmanaged, you
re-calculate
your desired size and call XtMakeResizeRequest to tell your parent you
want a
new size.
3. IN your Realize method (core class part's realize field), you do
the same as
#2 above.
4. In youyr GeometryManager method (composite class part's
geometry_manager
field), which is called when a child wants to change size, you also do
the same
as #2 above after re-determining your desired size.
--
Fred Kleinschmidt

Adding the Realize method did the trick ... a little sleazy, if you
ask me, but it works. Thanks!

[Fred]

Post by Joe Sewell

Post by Fred

Post by Joe Sewell
I'm writing a composite widget (actually a subclass of XmManager) that
should span the entire width of its parent, unless a resource in the
composite widget itself says otherwise.
The problem is at Initialize time. The parent is doing its initial
geometry negotiations, so its core.width resource is 0. This is
obviously the right answer (or at least not the wrong answer) since
it's trying to determine how wide it needs to be. By the time the
parent knows how wide it wants to be, though, its children (including
my widget) isn't allowed to change its size.
I really don't want to put a StructureNotify event handler on the
parent, and setting up a zero-time timeout or workproc isn't all that
favorable, either. So far, though, those are the only solutions I can
come up with. I *don't* want to depend on the parent doing the heavy
lifting (e.g., forcing the parent to be an XmForm with my widget's
XmNrightAttachment constraint set to XmATTACH_FORM), though that may
be the most palatable solution.
Any suggestions other than those?

You don't do size negotiations in your Initialize method. Here's what
1. Create a QueryGeometry method (core class part's query_geometry
field) that is
called by your parent when the parent wants to know your preferred
size.
2. In your ChangeManaged method (composite class part's
change_managed  field)
that is invoked whenever a child of yours is managed or unmanaged, you
re-calculate
your desired size and call XtMakeResizeRequest to tell your parent you
want a
new size.
3. IN your Realize method (core class part's realize field), you do
the same as
#2 above.
4. In youyr GeometryManager method (composite class part's
geometry_manager
field), which is called when a child wants to change size, you also do
the same
as #2 above after re-determining your desired size.
--
Fred Kleinschmidt

Adding the Realize method did the trick ... a little sleazy, if you
ask me, but it works. Thanks!- Hide quoted text -
- Show quoted text -

The reason for doing this in the Realize method is to reduce the
amount
of work that needs to be done.
.
Consider what happens when you create your widget, then sequentially
create 10 children of that widget, then manage your widget. It only
has to
do the size negotiations once. If it were done before being realized,
the
negotiations would have been done eleven times, a substantial waste
of CPU cycles.
--
Fred Kleinschmidt