Submitted by Anonymous on Mon, 05/21/2001 - 19:45. Developers
Can sibling widget manage another sibling widget under Motif 1.2, DX1.5, and HPUX 1020?
If not any suggestions would be welcome
Summary
I have a dialog window that has a little bit of space left for new widgets. (the customer does not want to have to use a scroll bar to move down)
My strategy is this
Display two-columned XiDBRadiobox(child of an XiColumn)
-if the first button is pressed, have XiColumn display three lines of XiDBdataField widgets
-if the 2nd button is pressed, have XiColumn display two different lines of XiDBdataField widgets
-if any other button is pressed, XiColumn will not display any additional XiDBdataField widgets.
So at most there will be three addition lines of XiDBdataField widgets.
At least, there will be zero lines of XiDBdataField widgets.
1) The parent widget is XiColumn (based on XmRowColumn)
2) A child widget is XiDBRadioBox (based on motif`s but has the annoying feature of not being made up of XmPushButtons! But I digress)
3) I need to know the "value" of this widget (which button is pressed), and I learn that by using the XmNvalueChanged resource to use a pointer (call_data) to XiValidateCallbackStruct, to then determine the value of that XiDBRadioBox widget after it is changed by the user.
4) Based on this single-character stringed value, I want to manage or unmanage some of the XiColumn`s other children, mainly a couple of XiDBdataFields.
Can this be done without getting too ugly?
Thanks, newdebugger
Sure it can be done and its not to ugly either ;)
If i understand you correctly the easy and common way of doing this would be to
create some structure which will hold all the possible XiDBdataField widgets, perhaps of global scope but the narrower the scope the better (of course). when you get the callback from the first button press just manage the widgets you need. (make sure you create them first ;)
XtManageChild(mydataWidgets->widget1);etc....
did that help?
jim
First of all, thank you for making an attempt at answering my question.
However, I`m not sure I understood what you said.
Are you saying, YES, a sibling widget can manage another sibling?
Because I cannot find that in the documentation.
Only a parent can mangage a child.
I think you are saying
I create a structure holding the XiDBdataFiled widgets.
This structure is in the main c file (not the callback file)
> when you get the callback from the first button press
Remember, the XiDBradioBox does not have PushButtons. I think it is a primitive widget.
And callbacks do not return values.
> just manage the widgets you need. (make sure you create them first ;)
> XtManageChild(mydataWidgets->widget1);etc....
How is the parent supposed to know which value the XiDBRadiobox is in?
newdebugger
Ok, sorry, i am a bit confused with your first post. Here is what i have so far
1) you have an Xi Column Widget in a dialog shell. you have 5 different datafield widgets you can display at different times depending on which toggle button is pressed in a XiDBRadio box.
2) it sounds like the XiDBRadio box is static? there are three choices and they are always there? you press a toggle button in the XiDBRadio box to determine which of the Datafields are to be displayed?
If that is the case i would sugest that you not use the XiDBRadio box in the first place and use an XmRadioBox with radio buttons in it.Then create each of the possible Datafield widgets and save away the widget, then manage them in the callback for the radio box.
However, i dont think this is what you are trying to do and i am still a little confused. ;)
so, back to the original question, can a sibling manage another sibling widget?
yes, if you know the widgets name, or if you have a pointer to it.
If you know its name, get your parent widget, and then call XtNameToWidget(parent,name); this will return the widget you want
to manage, then call XtManage on it. You have to do this all in a callback somehow. there is no resource on a widget which will just manage some other widget at some point.
I hope i made myself clear. either way, let me know and we can fix this somehow ;)
BTW, sorry about the spelling .
jim
jimk gives a great deal of information, but I think the simple answer is "yes" -- but it is the question that is confusing. The question implies that one widget is necessary in the managing of another. This is true, but the API call is simply "XtManageChild()" with a single argument, the widget to manage (see http//www.motifzone.com/resources/man/XtManageChild.html). It is not a call of the form XtManageChild(widget, widget) or XtManageChild(sibling, widget) or something like that. You can simply name the widget which should be managed. This works because the widget, internally, contains a pointer to its own parent, and Xt can follow that pointer to find the parent, which it needs to notify in order to have the child managed.
With that said, the issue then becomes one of passing around the pointers to the widgets which you may be managing. That is, in the callback for widget A you are wishing to manage widgets B, C, and D. jimk suggests that B, C, and D go into a data structure. It can be global. It can also be a structure which you allocate and then assign as the XmNuserData value for widget A, so that you can re-acquire the values from the callback for widget A without needing a global; the pointer to the allocated structure can also be passed as the client_data argument to the callback set on widget A. A third technique, which jimk refers to, is to use XtNameToWidget (http//www.motifzone.com/resources/man/XtNameToWidget.html) to reacquire the values; from A, you use XtParent() to get to the common anscestor, then descend using XtNameToWidget to find B, C, and D.
A variation is to create B, C, and D only when necessary, and subsequently remanage them as above.
With your idea about XtNameToWidget, I was able to get on the right path and to figure out how to get it to work!
My only side-effect is when XiColumn initially displays, the spacing between the rows is HUGE (even though the resource itemSpacing never changed), until I click on one of my toggles that sends a callback to redisplay all the rows with the correct number of XiDBdataFields (thanks to you).
I finish explaining below
> BY jimk
> DATE 05/22/01 1429
> SUBJECT Can a "sibling" widget manage another "sib"?
>
> Ok, sorry, i am a bit confused with your first post. Here is what i have so far
> 1) you have an Xi Column Widget in a dialog shell. you have 5 different
Yes.
>datafield widgets you
> can display at different times depending on which toggle button is pressed in a >XiDBRadio box.
Yes.
>
> 2) it sounds like the XiDBRadio box is static?
No.
> there are three choices and they
>are always there?
No.
There are 8 toggles in my radiobox. If I press the 7th toggle, 2 of the 5 DataFields display.
If I press the last toggle, the other 3 of the 5 DataFields display. If I press toggles 1-6, 0 of the 5 Datafields display. This is all because there is so much other stuff on this one dialog shell, I wanted to save space, so the customer wouldn`t have to use the vertical scrollbar.
> you press a toggle button in the XiDBRadio box to determine which of
> the Datafields are to be displayed?
Yes.
>
> If that is the case i would sugest that you not use the XiDBRadio box in the >first place and use
> an XmRadioBox with radio buttons in it.
Can`t do that because XmRadioBox does not work with our database in the same way that XiDBRadioBox does.
>Then create each of the possible
>Datafield widgets and
> save away the widget, then manage them in the callback for the radio box.
>
> However, i dont think this is what you are trying to do and i am still a little >confused. ;)
>
> so, back to the original question, can a sibling manage another sibling widget?
> yes, if you know the widgets name, or if you have a pointer to it.
> If you know its name, get your parent widget, and then call >XtNameToWidget(parent,name); this
> will return the widget you want
> to manage, then call XtManage on it. You have to do this all in a callback >somehow. there is no
> resource on a widget which will just manage some other widget at some point.
> I hope i made myself clear. either way, let me know and we can fix this >somehow ;)
> BTW, sorry about the spelling .
> jim
It`s ok! Like I said, you got me on the right track...I just have to fix this space problem!!!
-newdebugger
>jimk gives a great deal of information, but I think the simple answer is "yes" -- but it is
>the question that is confusing.
My question isn`t all that`s confusing, the function name, and definition XtManageChild
is also confusing!
According to Douglas A. Young`s book, The X Window System Programming and Apps
with Xt 2nd ed OSF Motif Edition, page 37
Managing Widgets
"All widgets except shell widgets must be managed by a parent widget."
It did not say a "sibling", or an "uncle" or a "third cousin twice removed" widget ).
Silly me for being confused!
>The question implies that one widget is necessary in the
>managing of another. This is true, but the API call is simply "XtManageChild()" with a
>single argument, the widget to manage (see
>http//www.motifzone.com/resources/man/XtManageChild.html). It is not a call of the
>form XtManageChild(widget, widget) or XtManageChild(sibling, widget) or something
>like that. You can simply name the widget which should be managed. This works
>because the widget, internally, contains a pointer to its own parent, and Xt can follow
>that pointer to find the parent, which it needs to notify in order to have the child
>managed.
Ah?.
>With that said, the issue then becomes one of passing around the pointers to the
>widgets which you may be managing. That is, in the callback for widget A you are
>wishing to manage widgets B, C, and D. jimk suggests that B, C, and D go into a data
>structure. It can be global. It can also be a structure which you allocate and then assign
>as the XmNuserData value for widget A, so that you can re-acquire the values from the
>callback for widget A without needing a global;
That`s another idea I should try.
> the pointer to the allocated structure can
>also be passed as the client_data argument to the callback set on widget A.
Well, what I did was use a string of widgetnames, and set it to a WidgetList and sent it
through client_data. Using XtNameToWidget below, and I didn`t have to declare anything global, although the widgetList was static which I free at the end of the callback.
> A third technique, which jimk refers to, is to use XtNameToWidget
>(http//www.motifzone.com/resources/man/XtNameToWidget.html) to reacquire the
>values; from A, you use XtParent() to get to the common anscestor, then descend using
>XtNameToWidget to find B, C, and D.
>A variation is to create B, C, and D only when necessary, and subsequently remanage
>them as above.
Ummm?I figured it would be at least just as complicated to create/destroy vs.
manage/unmanage.
But thanks for all the help!
newdebugger