grywalski@idicl1.idi.battelle.org (12/28/90)
There may be a simple answer to this question but I have consulted the FAQ and all the doc that I can get my hands on and have not been able to find it. What is the best way to obtain a list of all the children of a widget like the Motif RowColumn widget? DEC provided a DwtChildren call that returned a WidgetList given a CompositeWidget in it's toolkit. I have not been able to find a simular function under Motif. Thanks in advance... -- * Roger Grywalski - Software Developer GRYWALSKI@IDICL1.IDI.BATTELLE.ORG * Information Dimensions Inc. * 655 Metro Place South * Dublin, Ohio 43017
sydorow@bisco.kodak.com (Steve Sydorowicz) (12/29/90)
grywalski@idicl1.idi.battelle.org writes: > There may be a simple answer to this question but I have consulted >the FAQ and all the doc that I can get my hands on and have not been able to >find it. What is the best way to obtain a list of all the children of a widget >like the Motif RowColumn widget? DEC provided a DwtChildren call that >returned a WidgetList given a CompositeWidget in it's toolkit. I have not been >able to find a simular function under Motif. Thanks in advance... You can use XtSetArgs/XtGetValues setting up XmNchildren & XmNnumChildren. These resources are inherited for any subclass of Composite and are of type WidgetList (array) and Cardinal respectively. These resources are *READ-ONLY*, so don't muck with 'em ;-) -- -------------------------------------------------------------------------------- Stephen J. Sydorowicz Azatar Computer Systems REPLY TO: sydorow@bisco.kodak.com (716)726-5636 Opinions expressed are "mine and mine alone."
argv@turnpike.Eng.Sun.COM (Dan Heller) (12/30/90)
In article <20.277b089c@idicl1.idi.battelle.org> grywalski@idicl1.idi.battelle.org writes: > There may be a simple answer to this question but I have consulted > the FAQ and all the doc that I can get my hands on and have not been able to > find it. What is the best way to obtain a list of all the children of a widget > like the Motif RowColumn widget? Widget *children; int num_children, i; XtVaGetValues(row_col, XtNchildren, &children, XtNnumChildren, &num_children, NULL); for (i = 0; i < num_children; i++) printf("Child #%d: %s\n", XtName(children[i])); -- dan ---------------------------------------------------- O'Reilly && Associates argv@sun.com / argv@ora.com Opinions expressed reflect those of the author only.
grywalski@idicl1.idi.battelle.org (12/31/90)
In article <20.277b089c@idicl1.idi.battelle.org>, grywalski@idicl1.idi.battelle.org writes: > find it. What is the best way to obtain a list of all the children of a widget > like the Motif RowColumn widget? Thanks to everyone who replied to my question. I received many replies suggesting I do a XtGetValues on the XmNchildren, and XmNnumChildren resources of the composite widget class. Unfortunately I have Motif 1.0 which is still under R3. The *children resources were introduced with R4. Until I get Motif 1.1 it was suggested that I "cheat a little" and do the following: (Which seems to work fine by the way...) #include <X11/IntrinsicP.h> #include <X11/Intrinsic.h> #include <X11/Composite.h> #include <X11/CompositeP.h> WidgetList GetChildren(w) CompositeWidget w; { return w->composite.children; } int GetNumChildren(w) CompositeWidget w; { return w->composite.num_children; } -- * Roger Grywalski - Software Developer | GRYWALSKI@IDICL1.IDI.BATTELLE.ORG * Information Dimensions Inc. | * 655 Metro Place South | * Dublin, Ohio 43017 |
pasturel@sctc.com (Pierre Pasturel) (01/03/91)
grywalski@idicl1.idi.battelle.org writes: >#include <X11/IntrinsicP.h> >#include <X11/Intrinsic.h> >#include <X11/Composite.h> >#include <X11/CompositeP.h> >WidgetList GetChildren(w) > CompositeWidget w; >{ > return w->composite.children; >} >int GetNumChildren(w) > CompositeWidget w; >{ > return w->composite.num_children; >} As an observation, I thought that one should never include both IntrinsicP.h and Intrinisic.h (and the same goes with Composite include files). One of the OSF/Motif 1.0 manuals had a demo program which did include both, and this lead to much frustration later on when I found out that some fucntion protocols (e.g. XtScreen, XtDisplay,..) in Intrinsic.h were being redefined by macro defines in IntrinsicP.h by #include-ing the former followed by the latter, and this resulted in core dumps when I tried using the functions. I was told later by someone on this newsgroup never to include both, but I can't remember exactly why. Does it depend on your environment (i.e. will it work for some but not for others) ???? Its problems like these that should be inserted in a Commonly-Asked-Questions- and-Problems. I could list more things that beginner Motif programmers should look out for, but that would take too long :) Pierre pasturel@sctc.com
marbru@attc.UUCP (Martin Brunecky) (01/04/91)
In article <1991Jan2.185621.20296@sctc.com> pasturel@sctc.com (Pierre Pasturel) writes: >grywalski@idicl1.idi.battelle.org writes: > >>#include <X11/IntrinsicP.h> >>#include <X11/Intrinsic.h> > >As an observation, I thought that one should never include both >IntrinsicP.h and Intrinisic.h (and the same goes with Composite include >files). Xm.h includes Intrinsic.h, XmP.h includes IntrinsicP.h. So if you used those Motif header files, you'v got Xt headers as well. > >One of the OSF/Motif 1.0 manuals had a demo program which did include >both, and this lead to much frustration later on when I found out >that some fucntion protocols (e.g. XtScreen, XtDisplay,..) in Intrinsic.h >were being redefined by >macro defines in IntrinsicP.h by #include-ing the former followed by the >latter, and this resulted in core dumps when I tried using the functions. > No. IntrinsicP.h does include Intrinsic.h, and since this file uses #define _XtIntrinsic_h to prevent repeated definition, any subsequent inclusion of Intrinsic.h simply does nothing. Unless you #undef _XtIntrinsic_h in the meantime or did something else wrong. However. The xyzP.h are "private" header files, and as such should NOT be used in application code. The xyzP.h header files should only be used inside the *toolkit* components, such as widgets and supporting code. Whenever you include the "P.h" file, you are extending the toolkit - and that should NOT be part of your "normal" application code. When it comes to header files which include another header files, my own philosophy is that every include file should be self-supporting, ie. include all it's prerequisites, so that I could compile it directly and get no errors. Thus, ToggleBP.h would include everything from the LabelP.h down ... Unfortunatelly, some compilers have limits on header files nesting, and thus my self-supporting approach does not always work, as I am usually at the bottom of the hierarchy. Then I must resort to kluges like including Intrinsic.h firts, explicitly, instead letting the hierarchy of include files do it for me. -- =*= Opinions presented here are solely of my own and not those of Auto-trol =*= Martin Brunecky {...}sunpeaks!auto-trol!marbru (303) 252-2499 (sometimes also: marbru@auto-trol.COM ) Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
pasturel@sctc.com (Pierre Pasturel) (01/04/91)
>As an observation, I thought that one should never include both >IntrinsicP.h and Intrinisic.h (and the same goes with Composite include >files). I set up the includes like I did based on some example code in Douglas A. Young's book "The X WINDOW SYSTEM Programming and Applications with Xt" OSF/MOTIF edition. It seems to work fine for me. Looking into it further, my X11/IntrinsicP.h header file includes X11/Intrinsic.h anyhow so I don't see a problem. I am on VMS though and this may make a difference. -- * Roger Grywalski - Software Developer | GRYWALSKI@IDICL1.IDI.BATTELLE.ORG * Information Dimensions Inc. | * 655 Metro Place South | * Dublin, Ohio 43017 | **************************************************************************** Ok, I remember, the problem was not the order in which the include files are included (as you pointed out, IntrinsicP.h includes Intrinsic.h), but the problem I had was that some functions were being redefined by IntrinsicP.h which always returns a value of 0 which was used by another function, resulting in a core dump. For example, Intrinsic.h had the following fucnction prototypes: extern Display *XtDisplay(); /* Widget widget; */ extern Screen *XtScreen(); /* Widget widget; */ extern Window XtWindow(); /* Widget widget; */ which are then redefined by IntrinsicP.h as follows: #define XtDisplay(widget) ((widget)->core.screen->display) #define XtScreen(widget) ((widget)->core.screen) #define XtWindow(widget) ((widget)->core.window) The three macros were returning a value of 0 (I guess those core fields were not initialized). I don't know why they are zero, but when I did not include IntrinsicP.h, the function protocols in Intrinsic.h worked fine (they returned legitimate display, screen, and window numbers). So, what I don't know is why I have zero screen->display, screen, and window widget fields. Any ideas on that?? I am running OSF/Motif 1.0 with X11R4 on a 3/60 with SUN OS 4.0.3 Pierre pasturel@sctc.com
graham@fuel.dec.com (kris graham) (01/05/91)
> One of the OSF/Motif 1.0 manuals had a demo program which did include > both, and this lead to much frustration later on when I found out > that some fucntion protocols (e.g. XtScreen, XtDisplay,..) in Intrinsic.h > were being redefined by > macro defines in IntrinsicP.h by #include-ing the former followed by the > latter, and this resulted in core dumps when I tried using the functions. The XtDisplay ..etc function causing core dumps is a behaviour ;-) that was introduced with the advent of X11R4/Motif 1.1. There are some talks about incompatible specs between R3 and R4. I noticed this too when moving some applications from Motif 1.0.x to 1.1. Use XtDisplayOfObject() to get around this problem. XtDisplayOfObject(object) Widget object ; /* object whose display is to be returned */ Christopher Graham Digital Equipment Corp Ultrix Resource Center New York City Internet: graham@fuel.enet.dec.com UUCP: ...!decwrl!fuel.enet.dec.com!graham