Conference bulova::decw_jan-89_to_nov-90

    I don't understand why the main window is override redirect.
    
    The result you've described is correct:  The pop to front and push to
    back action of the window manager is overriden.
    
    The stacking order of windows is not obtainable from X. So your
    application needs to XRaiseWindow (XtWindow(popup_widget)) or
    XtUnmanageChild() XtManageChild() whenever it thinks the popup has been
    obscured.  One likely way of knowing this is when an Expose event has
    been received for the main window.  You can do this with translations
    management.  This is all possible but does it make sense?
    
    I think the conference might be in a better position if you could give
    us a higher-level description of what you are trying to accomplish.
    
    Applications typically cooperate with the window manager (which
    controls stacking order) and the widgets (which assign the cursor
    associated with a window)

At the risk of stating the obvious....

Have you forgotten/ did you know that Shift/Mouse button 1 in the `push behind' 
window causes it to stay behind. Could this not be actioned (by code) at start
up of your chosen window, giving your desired results?

Or am I missing something? Is WM doing all this good stuff?

Peter

That would be nice (stick to back at start). Can this be done?
Is it user proof?


re .1:
What I'm trying to do:

	This is an application which is used at RZxx disk drive vendor
	sites as a final production quality audit.  It basically does
	a bunch of drive/SCSI check out's before the vendor ships the
	thing to DEC.

	Since this run in a production environment it needs to be real
	simple to operate and "user proof". 

	application is run directly from DECW$LOGIN.COM, and when
	exits, the session is logged out and the start session is
	started (thanks to some DCL provided by this conference!).
	The application's display covers over the whole screen and disables
	the window manager so the user can't get to anything else.

	Since it runs directly from DECW$LOGIN, and control is never returned
	to the session manager, the mouse cursor stays as a watch so I
	hace to change it back to the X. This works fine until I pop up
	a dialog box (to either get info from the user (like serial number)
	or to display some error condition).  In the past I used MODAL boxes
	to insure they stay on top.  With MODAL boxes, the mouse cursor
	apparently can't be changed so it always switches back to the
	watch when the mouse moves over it. This would be confusing to the user!

	I tried MODELESS boxes and the mouse changes fine, but now a misguided
	click causes them [dialog box]  to dissappear behind the main window
	with NO WAY of getting them back (WM is disabled).


I'm trying the XRaiseWindow workaround now...

Is there a better way?


John

> Now I tried to use modal popups, but then I can't reset the watch pointer
> so when the user moves into the popup, it changes back to a watch!

I can't think of any reason why changing the cursor in a modal dialog
box should be any different from a modeless one.  Could you post your code
that changes the cursor?

Leo

First of all, this is REAL WIERD!  I tried using XRaiseWindow and it ended up
killing my window manager (only if OverrideRedirect is TRUE) and popping
every other window on top as well.

Then I logged into a VT220 sitting here on my desk and typed

$ set display /create/node=0/trans=local
$ RUN SYS$SYSTEM:decw$winmgr

This seemed to get half up and stop (a couple windows got partial title bars).

I then did @DECW$STARTUP RESTART to try again...

Logged in, got my background and an empty icon box, AND another start session
box?!?  

So I logged into that one (just for kicks). BOTH sessions then startup up.

I now have 1 icon box with TWO session managers and 2 of everything I
normally startup at login!  


Better forget this reply and go to the next which posts the change pointer
code.



John (who's now amusingly confused)

/*
 * Stuff for resetting the mouse cursor shape to the "X"
 *
 */
XColor  RZCurFore = {0, 0, 0, 0, 0, 0};
XColor  RZCurBack = {0, 0, 0, 0, 0, 0};
XColor  ExactFore = {0, 0, 0, 0, 0, 0};
XColor  ExactBack = {0, 0, 0, 0, 0, 0};
Font    CursorFont;
Cursor  RZCursor;


	.
	.
	.


/*
 * Set up the mouse cursor
 */
CursorFont = XLoadFont(XtDisplay(W_top), "DECw$Cursor");
XAllocNamedColor(XtDisplay(W_top),
                 XDefaultColormapOfScreen(XtScreen(W_top)),
                 "White",
                 &RZCurBack, &ExactBack);
XAllocNamedColor(XtDisplay(W_top),
                 XDefaultColormapOfScreen(XtScreen(W_top)),
                 "Black",
                 &RZCurFore, &ExactFore);
RZCursor = XCreateGlyphCursor(XtDisplay(W_top),
                                CursorFont,
                                CursorFont,
                                decw$c_x_cursor,
                                decw$c_x_cursor+1,
                                &RZCurFore,&RZCurBack);


	.
	.
	.


Then later:


Widget  W_mb;
char    buf[256],buf2[256];


   GetMsgText(status,buf);
   sprintf(buf2,"***  PROBLEM  REPORT ***\n\n- %s -",buf);
   XtSetArg(arglist[0],DwtNx, (MW_WIDTH/2-100));
   XtSetArg(arglist[1],DwtNy, (MW_HEIGHT/2-100));
   XtSetArg(arglist[2],DwtNforeground,BG);
   XtSetArg(arglist[3],DwtNbackground,FG);
   XtSetArg(arglist[4],DwtNyesCallback,CB_WAIT);
   XtSetArg(arglist[5],DwtNstyle,DwtModeless);

   W_mb = DwtMessageBoxCreate(W_dialog,
                           buf2,
                           arglist,
                           6);
   XtManageChild(W_mb);
   XDefineCursor(XtDisplay(W_mb),XtWindow(W_mb),RZCursor);
   Wait_Here(W_mb);
   XtUnmanageChild(W_mb);
   XtDestroyWidget(W_mb);

re .5 (my last reply).

I just discovered why it killed my window manager. I was trying to pass
the widget id of the one to to a ZRaiseWindow on, and it was stack local
in the calling function...


The change cursor code still dosen't work on modal boxes...


John (with red face)

    What does "Wait_Here" do?  I'm wondering if the XDefineCursor
    request ever gets "flushed"...
    
    Leo

int Wait_Here(w)
Widget w;
{
LONG    ef;

while(1) {
   sys$readef(EFN_BASE,&ef);                    /* Get event flags */
   if(ef&(1<<WAIT_HERE_EFN-EFN_BASE)) {         /* User acknoledge? */
      sys$clref(WAIT_HERE_EFN);
      return(SS$_NORMAL);
   };
   sleep(1);
   XRaiseWindow(w);             /* Keep message window on top! */
   ProcessXQueue();
};
}


Clicking on OK or ACKNOWLEDGE calls this callback:

void CB__WAIT(widget,tag,reason)
Widget  widget;
LONG    tag,*reason;
{
sys$setef(WAIT_HERE_EFN);
}



now I know the loop with sleep(1) is rather nasty on a multi user machine, but
this application is ALL that's going on...

RE: .7

The window manager ought to be more tolerant of bad input than that.  I suggset
QARing that crash.

--PSW

Leo, did you see any reason why modal dialog boxes won;t let the mouse pointer
be changed?

John

Sorry, but I don't see anything in your code to explain the problem...

Leo

Strange.  It works fine under the HPWM window manager...


John

Leo,
Looks like this may have been a queue flushing problem as you thought.

While I do call my ProcessXQueue() routine, IT doesn't call XFlush().

I suspected this cause when I put in a call to XRaiseWindow, things 
started working with the MODAL boxes. I think the call to XRaiseWindow
generated enough events (exposure etc) to cause XLIB to flush the queue
and get my XChangePointer request through.

Sound logical?

I'll try some variations and post the results...

John

    Certainly is possible...  Let me know what happens.
    
    Leo

Looks like it was something like that. Putting XFlush() in the ProcessXQueue()
call works as well.


Here is ProcessXQueue() :


void ProcessXQueue()
{
XtInputMask     EventMask;

XFlush(XtDisplay(W_top));		/* Flush XLIB queue */

while(EventMask = XtPending())          /* flush outstanding events */
   XtProcessEvent(EventMask);

}