Unmanaged buttons in dialogs

Unmanaged buttons in dialogs

Post by JF Meze » Fri, 03 Dec 2004 21:38:34


I am converting UIL structure to a C program.

The "arguments" section is easy to translate to C programming with XtSetArg
and passing args to the XmCreate_______ function.

In UIL, one defines the list of children when defining the parent.
In C, you attach children to a parent when you create each child.

In UIL, when you create XmTemplateDialog widget that comes with lots of
goodies, you can:

controls { Xm_Help unmanaged ; };

and this will remove the Help button that would normally appear at the bottom.
(This is used often in all sorts of widgets).

How does one translate this to a C program ?

After I have use the appropriate XmCreate_____ function, what else must I do
to signal to the widget that I don't want one of its children to be managed
when I do realise/manage the whole widget ?

Or must I manage the whole instance and then after that unmanage the
individual buttons ?
(and how would I know how they are called ?)
 
 
 

Unmanaged buttons in dialogs

Post by Fred L. Kl » Fri, 03 Dec 2004 23:59:34


XtUnmanageChild( XmMessageBoxGetChild(dialog, XmDIALOG_HELP_BUTTON) );

--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Common User Interface Services
M/S 2R-94 (206)544-5225

 
 
 

Unmanaged buttons in dialogs

Post by JF Meze » Sat, 04 Dec 2004 01:21:25


Many thanks.
 
 
 

Unmanaged buttons in dialogs

Post by arahn » Sat, 04 Dec 2004 02:21:11

> XtUnmanageChild( XmMessageBoxGetChild(dialog, XmDIALOG_HELP_BUTTON) );

XmMessageBoxGetChild is obsolete, should be
XtUnmanageChild(XtNameToWidget(dialog, "*Help"));

I actually had problems with that on SUSE 9.2

Best regards,

Dusan Peterc
 
 
 

Unmanaged buttons in dialogs

Post by Fred L. Kl » Sun, 05 Dec 2004 00:18:32


And it was a very stupid thing for OpenMotif to do. Using XtNameToWidget
is fraught with potential for getting the wrong widget, especially when
the base widget allows the application to add widgets. What happens if
the application adds a new child - even a dialog - that it names "Help"
? It is arbitrary as to which widget would be returned. I know, the
programmer should name it something else, but the potential is there,
and such a "bug" would be very, very difficult for most programmers to
find.

The whole point of all of the Xm...GetChild() functions was to ensure
that there was an easy, efficient, and foolproof way to obtain specific
children of a composite, without having to search through the quarked
names of all of the children.

Eliminating any of these convenience functions is a terrible idea.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Common User Interface Services
M/S 2R-94 (206)544-5225
 
 
 

Unmanaged buttons in dialogs

Post by arahn » Tue, 07 Dec 2004 04:18:11

> > XmMessageBoxGetChild is obsolete, should be


I don't argue with that.
One could, of course, also claim that XtNameToWidget is cleaner,
since it does not depend on the class of the parent, and could be
be viewed as more "object oriented" in its own twisted way.
But that is beyond the point.
I need to write software that compiles unchanged on all 2.x
versions of Motif, so this is what I have to use.
OpenMotif's maintainers should not take all the blame, since
these functions were marked as obsolete 8 years ago, and most
evolving toolkits do not keep obsolete functions forever.
I just wish it evolved faster in the directions of the
proclaimed goals (Antialiased fonts and UTF-8).

Best regards,

Dusan Peterc