bug#6468: A couple of problem related to frame raising (partly w32)

[Lennart Borgman]

After struggling with the getting raise-frame to workaround the
current problems with raise-frame I gave up. There are a couple of
problems so I am not sure where to begin.

I think the basic problem is that there is no hook so you can be sure
when a call to raise-frame (and other frame functions) will work after
frame creation. Since part of the frame creation as I understand it is
done asynchronously be the OS/window manager I think this is a really
basic need to get Emacs to work.

But I tried to do the raise-frame in a hook to and that does not work
either in all situations and I am not quite sure why.

One problem is that the system API calls currently is not checked and
partly in bad order. Here is the relevant part from w32fns.c:

    case WM_EMACS_SETFOREGROUND:
      {
        HWND foreground_window;
        DWORD foreground_thread, retval;

        /* On NT 5.0, and apparently Windows 98, it is necessary to
           attach to the thread that currently has focus in order to
           pull the focus away from it.  */
        foreground_window = GetForegroundWindow ();
        foreground_thread = GetWindowThreadProcessId (foreground_window, NULL);
        if (!foreground_window
            || foreground_thread == GetCurrentThreadId ()
            || !AttachThreadInput (GetCurrentThreadId (),
                                   foreground_thread, TRUE))
          foreground_thread = 0;

        retval = SetForegroundWindow ((HWND) wParam);

        /* Detach from the previous foreground thread.  */
        if (foreground_thread)
          AttachThreadInput (GetCurrentThreadId (),
                             foreground_thread, FALSE);

        return retval;
      }

The first call to GetWindowThreadProcessId should not be done if the
call to GetForegroundWindow does not succeed.

If there had been error checking this problem should have been
detected long ago. I have suggested adding that but the answer so far
has not been positive. In my opinion this is a huge waste of time. (I
can surely add this to my patched version but in the current situation
where I unfortunately have to keep a lot of bug fixes in my code it
costs my just too much time.)

Next problem is that if foreground_window is not 0 then the value of
foreground_thread will be erased if do not misunderstand the C
priorities. Can someone please confirm/disconfirm this?