[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::motif

Title:"OSF/Motif" is a trademark
Notice:MOTIF kit note in 7.*
Moderator:GOOEY::GRASS
Created:Mon Aug 07 1989
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5973
Total number of notes:24620

5922.0. "PRIMARY_APPLICATION_MODAL can prevent Xserver from 'seeing' mb events" by PEACHS::BRIDGES (MCS where the rubber meets the road) Tue Feb 04 1997 17:21

	Cross-posted in the DECwindows and the Motif notes conferences.

	Hello,

	I've a customer who reports their application programatically
	manages popup dialogs.  They have noticed "inappropriate behavior".  
	So far, I've reproduced the described behavior on;
	AlphaStations running:
		- VMS V6.2* and decwindows Motif v1.2-3	and v1.2-4, 
		- Digital unix v4.0b 
	but not on OpenVMS VAXstations V6.* with decwindows Motif v1.2-4 
	(FWIW)...

	I've reproduced using VMS - DECburger* and Dux - motifbur*

	o modify DECburger.uil/motifbur.uil so that the 
	  control_box: XmBulletinBoardDialog  
			XmNdialogStyle = XmDIALOG_PRIMARY_APPLICATION_MODAL;

	o In DECburger.c/motifbur.c modify the XtAppContext
	  app_context declaration to be global 

	o add a XtAppAddTimeOut( app_context, 10000, show_hide_proc, 0 );
	  to the show_hide_proc() callback so that the order entry dialog
	  is popped up and down every 10 seconds...

	o compile/link

	o pop up the order box
	
	o take it down or wait till it pops down on its own.

	o pull down one of the menus on the menu bar and leave it visible

	o wait till the order box pops up

	o click anywhere within the order box

	o your Xserver will no longer respond to mouse clicks.  

	You must kill the process running decburger/motifbur to get the
	Xserver to again respond to mb events...

	An ideas or just submit a IPMT case ?
	
	Thanks in advance,
	Bruce
T.RTitleUserPersonal
Name		DateLines
5922.1GERUND::WOLFEI'm going to huff, and puff, and blow your house downWed Feb 12 1997 23:0610
When a pulldown is on-screen it's doing some funky pointer grabs. The
modal dialog is doing the same so there are dueling grabs. This is 
no different from debugging an application and setting a breakpoint in
the activate callback of a menu pushbutton. Once you hit the breakpoint
you have wedged the system cause the grab is still outstanding. One
way to avoid this issue might be to add a map notify callback for the 
menu. When it's mapped, you can make sure not to popup any dialogs. 
This is definitely not IPMT material.  

			Pete
5922.2OK, but can you fill in a couple for me ?PEACHS::BRIDGESMCS where the rubber meets the roadThu Feb 13 1997 20:4447
    
    Hi Pete,
    
    	Thanks for the reply.
    
    >This is
    >no different from debugging an application and setting a breakpoint in
    >the activate callback of a menu pushbutton. Once you hit the breakpoint
    >you have wedged the system cause the grab is still outstanding.
    
    I like the analogy, but hitting a breakpoint in the debugger, is suspending
    execution of the application at the breakpoint with one grab active... 
    In this case, the modial dialog is managed while the menu is supposed to 
    have the pointer grabbed... so how do I explain to the customer the second 
    grab, i.e. the modal dialog is 'breakpointing' the application ?
    
    I know that the dialog must be responded to before some other action on
    the part of the ancestors widgets...  However, the customer asserts that 
    the toolkit and/or X11 should not allow the hang to occur.  The hang 
    occurs on Alpha Xservers, but not on VAX Xservers fwiw (in this case a lot 
    to the customer).
    
    I agree that using the map notif callback will get around the issue, I'm 
    just not clear on how the modal dialog grabs the grabbed pointer (ungrabs 
    from the menu ? almost...)
    
    I'm not attempting to mount an argument, really, I'm just trying to 
    determine which should have precedence (so the customer will not attempt
    to chew my head off) when I try to 'explain' the behavior to him. 
    Should it be;
    
    o the menu which has grabbed the pointer
    	or
    o the primary application modal dialog which is triggered by some real
      time event over which the biological unit at the keyboard has no 
      control and is merrily posting menues, until... 
    
    The customer argues that this state should not be reachable...  So, if
    I can appease the customer with map notify callback, I'll be happy.  If
    not, I'll need a pretty strong position as to why a menu pointer grab,
    followed by managing a modal dialog, is a draw resulting in a hang,
    mutex, or whatever, i.e. expected behavior.
    
    	Thanks for your patience and assistance
    
    	Regards,
    	Bruce