pasturel@sctc.com (Pierre Pasturel) (11/07/90)
Are the following bugs/problems/missing features in Motif 1.0???
1. I create a bulletinboarddialog widget whose parent is a mainwindow
widget. I animate the movement of this bulletinboard by
by changing the XmNx,XmNy of its PARENT dialog shell to set the x,y
coordinates (relative to the root window) of the WINDOW'S WORKING AREA.
When I first login in for the day, start my x session and mwm, and execute
my application program, the XmNx, XmNy coordinates occassionally (not
always) set the x,y coord. of the (top left corner of the) WINDOW FRAME. I
immediately re-execute my application again (no recompiles or anything),
and then it works correctly (ie.. the window is placed for the x,y coord.
of the window's working area). This inconsistency is annoying...
2. The XmNinsertionPointVisable is documented as a resource of a XmText
widget but does not work when set. I could not find its
string macro define in Xm.h.
3. I was trying to use the
XtParent(), XtScreen(), XtDisplay() functions in my application program
and I found that they always returned a 0. Turns out that my program
was including Instrinsic.h followed by IntrinsicP.h. The latter include
file re-defines the function prototypes defined in the former as macro
defines. For example, Intrinsic.h defines:
extern Screen *XtScreen(
#if NeedFunctionPrototypes
Widget /* widget */
#endif
);
while IntrinsicP.h defines:
#define XtScreen(widget) ((widget)->core.screen)
I guess the widget core.screen field was set to 0. Actually, the reason
why I ran into this mess was that I was using the xmfonts.c demo source
code as a model which includes Instrinsic.h followed by IntrinsicP.h. When
I tried running xmfonts, I found that it was giving me core dumps at the
following line of code:
font = XLoadQueryFont( XtDisplay( XtParent(parent)), name);
The source code listed for xmfonts.c in the OSF/Motif 1.0 programmer's guide
also shows the inclusion of those files in that order.
This leads to my questions: when is one suppose to include Intrinisc.h followed
by IntrinsicP.h? Why was the latter included in the xmfonts.c demo source
if it results in core dumps? I'm sure that someone tried to see if this
demo worked before shipping it.
Documentation in Intrinsic.h and IntrinsicP.h is non-existent so the programmer
has no idea what they are used for.
4. I've noticed that if you try to set the XmNvalue
and XmNcursorPosition resources for the a text widget
with the same XtSetValues call, then the XmNvalue
gets updated corectly, but the cursor position
SOMETIMES gets set to 0 despite setting it to a non-zero value.
I think that it has something to do with the internal
buffer that stores XmNvalue which must somehow be
empty when motif tries to set the cursor position because it then
thinks there are is no text and therefore the cursor position should
be set at the 0th position.
My "fix" is to make another XtSetValues call to
again set the XmNcursorPosition resource to the
desired non-zero value.
BTW, is there a list of "commonly asked questions about programming in
motif" somewhere so that people like us don't have to flood this newsgroup
with our basic questions?
Thanks
Pierre Pasturel
pasturel@sctc.comnazgul@alphalpha.com (Kee Hinckley) (11/07/90)
> When I first login in for the day, start my x session and mwm, and execute > my application program, the XmNx, XmNy coordinates occassionally (not > always) set the x,y coord. of the (top left corner of the) WINDOW FRAME. I > immediately re-execute my application again (no recompiles or anything), > and then it works correctly (ie.. the window is placed for the x,y coord. > of the window's working area). This inconsistency is annoying... I'm not totally sure I understand what you are saying. This app creates a dialog when it starts up? If so there is a problem that if the parent is not realized when the dialog is created the window will get placed at 0,0. Is that the problem? If so you probably have some kind of race condition. If not I have no idea. > 2. The XmNinsertionPointVisable is documented as a resource of a XmText > widget but does not work when set. I could not find its > string macro define in Xm.h. There's XmNcursorPositionVisible at 1.1, I'm not sure about 1.0. > This leads to my questions: when is one suppose to include Intrinisc.h followed > by IntrinsicP.h? Why was the latter included in the xmfonts.c demo source Never. Include one or the other. Not that it matters though, the first thing that IntrinsicP.h does is include Intrinsic.h. Are you sure that IntrinsicP.h is the one that comes with Motif 1.0 and not the R3 one? > Documentation in Intrinsic.h and IntrinsicP.h is non-existent so the programmer > has no idea what they are used for. You can't really use Motif without Intrinsics documentation. I believe that OSF's intention there is to refer you to the Intrinsics documentation rather than trying to duplicate it. > BTW, is there a list of "commonly asked questions about programming in > motif" somewhere so that people like us don't have to flood this newsgroup > with our basic questions? Yes, a preliminary copy was just posted. However most of your questions weren't in that category anyway. -kee
pasturel@sctc.com (Pierre Pasturel) (11/08/90)
>> When I first login in for the day, start my x session and mwm,and execute >> my application program, the XmNx, XmN coorXdinates occassionally (not >> always) set the x,y coord. of the (top left corner of the)WINDOW FRAME. I >> immediately re-execute my application again (no recompiles or anything), >> and then it works correctly (ie.. the window is placed for the x,y coord. >> of the window's working area). This inconsistency is annoying... >I'm not totally sure I understand what you are saying. This app creates a >dialog when it starts up? If so there is a problem that if the parent is not >realized when the dialog is created the window will get placed at 0,0. Is >that the problem? no Before I describe the problem in more detail, I am assuming that setting the XmNx,XmNy resources of the dialog shell parent of a bulletinboard widget will set the x,y coordinates of the bulletinboard window's top-left corner of the WINDOW WORKING AREA and **not** the window's frame. Correct me if I am wrong. The problem I am having is that the same program will sometimes use the XmNy,XmNx resources for the x,y coord. of the window's top-left corner of its frame (not what I expected), while most other times, it will (correctly) use the resources for the x,y coord. of the window's top-left corner of the WORKING AREA (below the frame, just to the right of the left border). A few observations/comments: 1. If motif decides to use the XmNx, XmNy resources to place the window frame, it does it consistently as I move the window by changing XmNy, XmNx resources in future calls to XtSetValues. If motif decides to use the resources to place the window's working area, it does it consistently as I change the resources. 2. I have noticed that when the bullentinboard is positioned correctly, the FIRST settings of the XmNy, XmNx resources appear to be used for the window frame (just for a fraction of a second), and then they will be shifted justly slightly up and to the left to position it for the window's working area. If this shifting does not happen, changes to the XmNx,XmNy resources will continue to position the window's frame and not the window's working area. 3. The reason that this is important for my application is that the bulletinboard is a user token (a smartcard, mag. strip card, if you will) that, when a pushbutton is pressed, moves from position (x1,y1), (x2,y2), ...... all the way to (xn,yn) where (xn,yn) is the position it MUST end up at so that it looks as if it has been entered in a control panel token slot. When the setting of the XmNx, XmNy resoures result in the positioning of the window's frame, the user token "misses" the slot because my code is written to position the window's working area. The sequence of events is as follows: 1. When my application first starts, it creates an application shell, whose only child is a bullentinboard with a couple of pushbuttons. This bulletinboad acts as a menu window. 2. When one of the buttons is activated, its callback is called which does te folelowing: o creates a top level shell o creates a mainwindow widget with the top level shell as its parent (this main_window has some children, but of no conern here) o creates a bullentinboarddialog with the mainwindow as its parent. When I iconify the (primary) mainwindow, I want all other windows created from pressing the pushbutton to be associated with the same icon. And because the toplevel shell can only have one child (as far as I could tell), I created all other windows with the main_window as the parent. o I then want to position the bullentinboard window using the XmNy,XmNx resources of the parent dialog shell. With a little trial-and-error, I find that it will only work if I set the XmNy,XmNy resource of the parent after I manage the child bulletinboard. The problem is here. /* Create a User Token with a mainwindow as its parent */ CreateUserToken(user_display); /* Manage the user token */ XtManageChild(user_token); /* note: resources can only be set after user_token has been managed */ XtSetArg (args[n], XmNx, 962 ); n++; XtSetArg (args[n], XmNy, 34 ); n++; XtSetArg (args[n], XmNtitle, " TOKEN "); n++; XtSetValues( XtParent(user_token), args, n); Sometimes the window's frame is positioned at (962,34), sometimes the window's working area. All subsequent calls to XtSetVAlues to set the XmNx, XmnNy resources of the parent dialog shell will be consistent with how it did it the first time. I don't see how this could be due to a race condition. Related Questions: 1. Of what type is a dialog shell? Is it simply a Shell? a VendorShell? a WMshell? Does the dialog shell for a bullentinboardialog child get managed when the child is managed? > >> This leads to my questions: when is one suppose to include Intrinisc.h followe >d >> by IntrinsicP.h? Why was the latter included in the xmfonts.c demo source >Never. Include one or the other. Not that it matters though, the first thing >that IntrinsicP.h does is include Intrinsic.h. Are you sure that IntrinsicP.h is the one that comes with Motif 1.0 and not the R3 one? > Found out that I'm using the R4 one. Don't know of any motif 1.0 one. How is it different? >> BTW, is there a list of "commonly asked questions about programming in >> motif" somewhere so that people like us don't have to flood this newsgroup >> with our basic questions? > >Yes, a preliminary copy was just posted. However most of your questions >weren't in that category anyway. That's why I asked for a PROGRAMMER's list of questions for the type of questions I have been asking. > > -kee > > Other Questions: 1. How can your ***application program*** change the mouse pointer from an arrow to an hour glass and back to an arrow? I want to do this to tell the user that (s)he needs to be patient for awhile. I don't want to use a workingdialog. 2. How can you prohibit the user from moving windows created by your application? Can you select which windows can be moved and which can't? Thanks for your responses. They have been most helpful. Pierre pasturel@sctc.com
pasturel@SCTC.COM (Pierre Pasturel) (11/08/90)
>> When I first login in for the day, start my x session and mwm,and execute >> my application program, the XmNx, XmNy coordinates occassionally (not >> always) set the x,y coord. of the (top left corner of the)WINDOW FRAME. I >> immediately re-execute my application again (no recompiles or anything), >> and then it works correctly (ie.. the window is placed for the x,y coord. >> of the window's working area). This inconsistency is annoying... >I'm not totally sure I understand what you are saying. This app creates a >dialog when it starts up? If so there is a problem that if the parent is not >realized when the dialog is created the window will get placed at 0,0. Is >that the problem? no Before I describe the problem in more detail, I am assuming that setting the XmNx,XmNy resources of the dialog shell parent of a bulletinboard widget will set the x,y coordinates of the bulletinboard window's top-left corner of the WINDOW WORKING AREA and **not** the window's frame. Correct me if I am wrong. The problem I am having is that the same program will sometimes use the XmNy,XmNx resources for the x,y coord. of the window's top-left corner of its frame (not what I expected), while most other times, it will (correctly) use the resources for the x,y coord. of the window's top-left corner of the WORKING AREA (below the frame, just to the right of the left border). A few observations/comments: 1. If motif decides to use the XmNx, XmNy resources to place the window frame, it does it consistently as I move the window by changing XmNy, XmNx resources in future calls to XtSetValues. If motif decides to use the resources to place the window's working area, it does it consistently as I change the resources. 2. I have noticed that when the bullentinboard is positioned correctly, the FIRST settings of the XmNy, XmNx resources appear to be used for the window frame (just for a fraction of a second), and then they will be shifted justly slightly up and to the left to position it for the window's working area. If this shifting does not happen, changes to the XmNx,XmNy resources will continue to position the window's frame and not the window's working area. 3. The reason that this is important for my application is that the bulletinboard is a user token (a smartcard, mag. strip card, if you will) that, when a pushbutton is pressed, moves from position (x1,y1), (x2,y2), ...... all the way to (xn,yn) where (xn,yn) is the position it MUST end up at so that it looks as if it has been entered in a control panel token slot. When the setting of the XmNx, XmNy resoures result in the positioning of the window's frame, the user token "misses" the slot because my code is written to position the window's working area. The sequence of events is as follows: 1. When my application first starts, it creates an application shell, whose only child is a bullentinboard with a couple of pushbuttons. This bulletinboad acts as a menu window. 2. When one of the buttons is activated, its callback is called which does the following: o creates a top level shell o creates a mainwindow widget with the top level shell as its parent (this main_window has some children, but of no conern here) o creates a bullentinboarddialog with the mainwindow as its parent. When I iconify the (primary) mainwindow, I want all other windows created from pressing the pushbutton to be associated with the same icon. And because the toplevel shell can only have one child (as far as I could tell), I created all other windows with the main_window as the parent. o I then want to position the bullentinboard window using the XmNy,XmNx resources of the parent dialog shell. With a little trial-and-error, I find that it will only work if I set the XmNy,XmNy resource of the parent after I manage the child bulletinboard. The problem is here. /* Create a User Token with a mainwindow as its parent */ CreateUserToken(user_display); /* Manage the user token */ XtManageChild(user_token); /* note: resources can only be set after user_token has been managed */ XtSetArg (args[n], XmNx, 962 ); n++; XtSetArg (args[n], XmNy, 34 ); n++; XtSetArg (args[n], XmNtitle, " TOKEN "); n++; XtSetValues( XtParent(user_token), args, n); Sometimes the window's frame is positioned at (962,34), sometimes the window's working area. All subsequent calls to XtSetVAlues to set the XmNx, XmnNy resources of the parent dialog shell will be consistent with how it did it the first time. I don't see how this could be due to a race condition. Related Questions: 1. Of what type is a dialog shell? Is it simply a Shell? a VendorShell? a WMshell? Does the dialog shell for a bullentinboardialog child get managed when the child is managed? > >> This leads to my questions: when is one suppose to include Intrinisc.h followe >d >> by IntrinsicP.h? Why was the latter included in the xmfonts.c demo source >Never. Include one or the other. Not that it matters though, the first thing >that IntrinsicP.h does is include Intrinsic.h. Are you sure that IntrinsicP.h is the one that comes with Motif 1.0 and not the R3 one? > Found out that I'm using the R4 one. Don't know of any motif 1.0 one. How is it different? >> BTW, is there a list of "commonly asked questions about programming in >> motif" somewhere so that people like us don't have to flood this newsgroup >> with our basic questions? > >Yes, a preliminary copy was just posted. However most of your questions >weren't in that category anyway. That's why I asked for a PROGRAMMER's list of questions for the type of questions I have been asking. > > -kee > > Other Questions: 1. How can your ***application program*** change the mouse pointer from an arrow to an hour glass and back to an arrow? I want to do this to tell the user that (s)he needs to be patient for awhile. I don't want to use a workingdialog. 2. How can you prohibit the user from moving windows created by your application? Can you select which windows can be moved and which can't? Thanks for your responses. They have been most helpful. Pierre pasturel@sctc.com