Unmanaged buttons in dialogs - Motif

This is a discussion on Unmanaged buttons in dialogs - Motif ; 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. ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Unmanaged buttons in dialogs

  1. Unmanaged buttons in dialogs

    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 ?)

  2. Re: Unmanaged buttons in dialogs



    JF Mezei wrote:
    >
    > 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 ?)


    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

  3. Re: Unmanaged buttons in dialogs

    "Fred L. Kleinschmidt" wrote:

    >
    > XtUnmanageChild( XmMessageBoxGetChild(dialog, XmDIALOG_HELP_BUTTON) );



    Many thanks.

  4. Re: Unmanaged buttons in dialogs

    > 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

  5. Re: Unmanaged buttons in dialogs



    arahne wrote:
    >
    > > 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


    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

  6. Re: Unmanaged buttons in dialogs

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


    > 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.


    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

+ Reply to Thread