Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ncar!ico!attc!marbru From: marbru@attc.UUCP (Martin Brunecky) Newsgroups: comp.windows.x.motif Subject: Re: Determining children widget IDs (Summary) Message-ID: <952@attc.UUCP> Date: 3 Jan 91 17:45:45 GMT References: <20.277b089c@idicl1.idi.battelle.org> <21.277e1314@idicl1.idi.battelle.org> <1991Jan2.185621.20296@sctc.com> Reply-To: marbru@auto-trol.UUCP (Martin Brunecky) Organization: Auto-trol Technology, Denver Lines: 52 In article <1991Jan2.185621.20296@sctc.com> pasturel@sctc.com (Pierre Pasturel) writes: >grywalski@idicl1.idi.battelle.org writes: > >>#include >>#include > >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