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

Conference bulova::decw_jan-89_to_nov-90

Title:	DECWINDOWS 26-JAN-89 to 29-NOV-90
Notice:	See 1639.0 for VMS V5.3 kit; 2043.0 for 5.4 IFT kit
Moderator:	STAR::VATNE

Created:	Mon Oct 30 1989
Last Modified:	Mon Dec 31 1990
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3726
Total number of notes:	19516

1194.0. "Modal msg box and grabbed keyboard" by AIDA::CARCANO (Matteo Carcano, Italian ACT Milan) Fri Jul 28 1989 11:40

In my application I have a dialog box with stext widget in it. 
I move from one stext to the other by using the mouse or the TAB. 
The stext widgets have a lost_focus callback that, in particular 
conditions, displays a modal message box by managing it.
 
Now comes the problem: if I use the pointer to change the focus
everything works fine and I can activate the push button in the msg 
box hitting the RETURN key (this "functionality" is a MUST).

But, if I try to change the focus using the TAB, what happens is that
the keyboard got grabbed by someone and not only for this specific
application but for all the clients using the same server. As a 
consequence 1) I can't input data anymore to the stext widgets
            2) the msg box's push button cannot be activated with the
               RETURN key
By the way: the pointer is still "active" (not grabbed, fortunately).

Does anyone have an explanation and a solution to this odd behaviour?

P.S. The msg box is created via UIL with style = DwtModal,
                                         take_focus = true,
                                         auto_unmanage = true.

P.P.S. Why a modeless msg box doesn't unmanage itself even if the
auto_unmanage resource is set to TRUE?

Thanks for the help I hope to get,

Matteo

T.R	Title	User	Personal Name	Date	Lines
1194.1		LEOVAX::TREGGIARI		`Fri Jul 28 1989 13:59`	28
	> But, if I try to change the focus using the TAB, what happens is that > the keyboard got grabbed by someone and not only for this specific > application but for all the clients using the same server. The dialog box has a passive grab for the Tab key in order to be able to move the input focus "synchronously" between fields. The problem you are seeing could happen in two cases (that I can think of - otherwise I don't understand how it could happen...): 1. You've overriden the translation for Tab and are not calling XAllowEvents or XUngrabKeyboard. 2. You are hitting 2 tabs quickly; that is, the first tab causes the modal dialog box to appear, and the second tab causes the problem. The problem in this case is that the modal dialog box prevents the Tab key from being dispatched to the dialog box with the text fields, and XAllowEvents is never called. Are you doing case 1 or 2? > P.P.S. Why a modeless msg box doesn't unmanage itself even if the > auto_unmanage resource is set to TRUE? The auto_unmanage resource is only support for modal dialog boxes. Leo
1194.2		AIDA::CARCANO	Matteo Carcano, Italian ACT Milan	`Wed Aug 09 1989 04:57`	46
	>The dialog box has a passive grab for the Tab key in order to be able >to move the input focus "synchronously" between fields. The problem >you are seeing could happen in two cases (that I can think of - otherwise >I don't understand how it could happen...): >1. You've overriden the translation for Tab and are not calling > XAllowEvents or XUngrabKeyboard. >2. You are hitting 2 tabs quickly; that is, the first tab causes the modal > dialog box to appear, and the second tab causes the problem. The > problem in this case is that the modal dialog box prevents the > Tab key from being dispatched to the dialog box with the text fields, > and XAllowEvents is never called. >Are you doing case 1 or 2? Well, the answer is neither 1 or 2. I didn't touch the translation for TAB and I'm not a video game player (I'm not so fast in hitting keys). However, your answer gives me an idea that is: I already had troubles with TAB when using it to change the focus. In fact what happens is that the lost_focus callback associated to the losing_focus stext is called twice (the mode field in the event structure is set once to NotifyGrab and the other time to something like NotifyWhileGrabbed). What I do is to check the field from within the callback and take no action in one of the two cases. Couldn't it be the same story in this case too? Unfortunately I don't know how to get into the routine that handles the TAB in order to discard one of the two events. (I know I can override the routine with a user written one but I don't want to lose the stext widgets management already implemented in the toolkit routine...) It's just a guess. If what I've written is garbage, please correct me. Have you any idea to work on? In any case, thanks a lot. Matteo.