Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!resq!Uucp
From: Uucp@resq.fidonet.org (Uucp)
Newsgroups: comp.windows.x.motif
Subject: Re: XmStringGetLtoR and Loss of Keyboard Focus
Message-ID: <33.27EF5233@resq.fidonet.org>
Date: 25 Mar 91 12:56:57 GMT
Organization: RES-Q, Paterson NJ  (201) 881-7421
Lines: 84

From  uunet!osf.org!motif-talk-request
From: uunet!alfalfa.com!nazgul (Kee Hinckley)
To:   larry@sunrise.com (Larry Rogers)
Date: Fri, 22 Mar 91 16:36:18 -0500
Cc:   motif-talk@osf.org

> By the way, was it you that asked about the loss of keyboard
> focus when using accelerators to bring up dialogs?  If it was,
> I did some research.  It appears to be a timing problem that
> occurs more frequently on some systems than others.  The
> DECstation 3100 we have fails every time you do two accelerators
> in a row.  The MIPS fails only once in a blue moon.  The Sun,
> almost never.
> 
> An easy fix that I incorporated into my code was to use
> XtUngrabKeyboard directly before displaying any dialog. Note
> that I only do this if the pop-up dialog shell's parent widget is
> realized and I pass the parent widget as a parameter to the routine.
> Because the routine checks for grab conditions before doing
> an XUngrabKeyboard, it causes no X errors and because it never
> uses the widget, except to get the display/screen info, it isn't
> too picky about what widget is used.

I'm getting sick and tired of this bug.  I don't see it, incidentally on my dialogs,
but rather on a main window that I invoke and close using accelerators.  It's
clearly a focus problem, because whenever it happens I can press Alt-F to
bring up the File menu and it will bring up the File menu in the *old* window.
In fact, it will even do this if the old window is no longer mapped.  Of course
this results in an X error when it unmaps it, but fortunately I trap those.

I tried what you suggested and indeed it did seem to make things better.  (It's
hard to tell exactly, since the problem doesn't happen reliably.)  However I
now get the case where the new window comes up and doesn't visibly have the
focus anywhere, but if I start typing I find that I'm in one of the text widgets.
*However* it turns out that the translations and accelerators don't work (this
is an improvement mind you, typing didn't used to work either).

So I poked around and I looked at the change_managed code in Vendor.c and
so I added the following code to my manage routine 

    if (shell && XtParent(shell) && XtIsRealized(XtParent(shell))) {
        XtUngrabKeyboard(XtParent(shell), CurrentTime);
        if (shell == widget) {
            Cardinal    numKids, i;
            Widget      *kids;

            arglist.add(XmNchildren, &kids, XmNnumChildren, &numKids, NULL);
            XtGetValues(shell, arglist.args, arglist.clear());
            for (i = 0; i < numKids; ++i) if (XtIsManaged(kids[i])) break;
            if (i < numKids) XtSetKeyboardFocus(shell, kids[i]);
        }
    }

I do that after a realize (if it's the first time) and before I map the window.

Note the parallels here with the Dialog code we've all been talking about.
Vendor shell is doing special stuff in its change_managed routine, even though
there are other times when a VendorShell will end up on the screen without going
through that code.

So.  This code in fact seems to work pretty well.  I now get the window coming
up and it usually has a focus indicator somewhere, and the times that it doesn't,
pressing TAB will make one appear.  All the translations seem to work all the time
too.  (Mind you, I've been using this for about half an hour, but the next time I
do something it might turn out I'm all wrong and it doesn't work.)

So.  Why am I still annoyed?  Well I take this window *down* on an accelerator too.
And doing stuff at window map time isn't going to fix that.  I'm going to go off
and do a XtUngrabKeyboard when I unmap the window and see what happens there.  Maybe
that will fix it, but I really hate this kind of stuff - I'm just playing in the
dark.  Does anyone who *knows* something care to comment?

And people really think they can write a virtual toolkit that hides Motif?  Drugs!

Alfalfa Software, Inc.          |       Poste:  The EMail for Unix
nazgul@alfalfa.com              |       Send Anything... Anywhere
617/646-7703 (voice/fax)        |       info@alfalfa.com

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
--  
Uucp - via FidoNet node 1:269/133
UUCP: uunet!resq!Uucp