Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!timbuk!cs.umn.edu!sctc.com!pasturel
From: pasturel@sctc.com (Pierre Pasturel)
Newsgroups: comp.windows.x.motif
Subject: Re: bugs/problems in motif 1.0
Message-ID: <1990Nov7.160109.28546@sctc.com>
Date: 7 Nov 90 16:01:09 GMT
References: <1990Nov6.161146.20690@sctc.com>
Distribution: comp.windows.x.motif
Organization: Secure Computing Technology Corporation
Lines: 135

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