Who gets the keyboard focus?

[Gyannea]

How does windows decide who gets the keyboard focus when a window is destroyed? I assumed that it would be the window from which the destroyed window was created.

I create a modeless dialog box from one of three main windows. Within the dialog function, a second modeless dialog box is created. When I then destroy modeless dialog box 2, then box 1, I do not come back to the window from which the dialog boxes started, but a second of three 'primary' windows gets the keyboard focus. Is this a bug in my code or is there something funny about calling nested modeless dialog boxes? (By the way, multiple copies of the dialog boxes are prevented, though all other activities of the remaining windows are possible.)

Look for coding bug, correct? Very possible as I have a complicated message loop since I convert keypresses to mouse clicks for button boxes. Involves tweaking of both the message loop and callback functions.)

[poccil]

This was taken from the wine code toillustrate the procedure:

/*******************************************************************
 *         can_activate_window
 *
 * Check if we can activate the specified window.
 */
static BOOL can_activate_window( HWND hwnd )
{
    LONG style;

    if (!hwnd) return FALSE;
    style = GetWindowLong( hwnd, GWL_STYLE );
    if (!(style & WS_VISIBLE)) return FALSE;
    if ((style & (WS_POPUP|WS_CHILD)) == WS_CHILD) return FALSE;
    return !(style & WS_DISABLED);
}


/*******************************************************************
 *         WINPOS_ActivateOtherWindow
 *
 *  Activates window other than pWnd.
 */
void WINPOS_ActivateOtherWindow(HWND hwnd)
{
    HWND hwndTo, fg;

    if ((GetWindowLong( hwnd, GWL_STYLE ) & WS_POPUP) && (hwndTo = GetWindow( hwnd, GW_OWNER )))
    {
        hwndTo = GetAncestor( hwndTo, GA_ROOT );
        if (can_activate_window( hwndTo )) goto done;
    }

    hwndTo = hwnd;
    for (;;)
    {
        if (!(hwndTo = GetWindow( hwndTo, GW_HWNDNEXT ))) break;
        if (can_activate_window( hwndTo )) break;
    }

 done:
    fg = GetForegroundWindow();
    if (!fg || (hwnd == fg))
    {
        if (SetForegroundWindow( hwndTo )) return;
    }
    if (!SetActiveWindow( hwndTo )) SetActiveWindow(0);
}

[filthy_mcnasty]

a goto in c++!?! *dies*

many years ago in my first c++ class i used a "goto" once because it what was known to me at the time (qbasic and whatnot). i dont think i've ever gotten as good a lecture than i did that day on how goto's are fine for other languages (basic, asm) but for c/c++ they are evil. so kill the goto in the code then all is well in la la land.

[Gyannea]

Peter O,

Thanks for the code, but that doesn't really address the question. Its just that I "call" modeless dialog box 1 from Window A, then from dialog box 1 I call modeless dialog box 2. Then I close dialog box 2 and return to dialog box 1. But when I close dialog box 1, I don't return to Window A. Start A, Open, open, close, close. Nothing else. Shouldn't I be back at A?

Brian

[TheCPUWizard]

filthy...If you removed the goto's from the windows code, there would be no windows.. unfortunate but true.

Gyannea...Poccil's did infact answer your question...The window that gets focus when some widow loses it, has absolutely nothing to do with the "history of focus". Rather it is totally dependant on internal structures.

To get the effect you want do a SetFocus before you kill the second dialog box..

Hope this helps...

[Gyannea]

It does help, but its clear that I didn't understand the code. It looked like it was asking for what the keyboard focus was. However, you did answered my question in a straight forward manner: the keyboard focus is controlled by a bunch of internal workings of which I possess no knowledge of, and the "calling window" does not automatically get the keyboard focus upon "return". I did not want to use 'SetFocus()' to get what I want if it shouldn't be necessary (which means I was compensating for a bug). So far in my limited windows coding experience, all one-level cases HAVE returned to the caller. I just assumed there was some type of PUSH-POP stack for these "windows".

THus Start -open-open-close-close does not (necessarily) get you back to start. It is common practice that one uses 'SetFocus()' when opening a dialog box?