emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#6468: closed (A couple of problem related to frame


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#6468: closed (A couple of problem related to frame raising (partly w32))
Date: Thu, 06 Oct 2011 20:36:02 +0000

Your message dated Thu, 06 Oct 2011 16:35:24 -0400
with message-id <address@hidden>
and subject line Re: bug#6468: A couple of problem related to frame raising 
(partly w32)
has caused the debbugs.gnu.org bug report #6468,
regarding A couple of problem related to frame raising (partly w32)
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
6468: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6468
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: A couple of problem related to frame raising (partly w32) Date: Sat, 19 Jun 2010 20:23:29 +0200
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?



--- End Message ---
--- Begin Message --- Subject: Re: bug#6468: A couple of problem related to frame raising (partly w32) Date: Thu, 06 Oct 2011 16:35:24 -0400 User-agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
tags 6468 notabug
stop

Eli Zaretskii wrote:

> Would you please describe the problem(s) you are talking about?
>
> How about a reproducible recipe for them?

This was never answered.

This isn't a bug a report, just a rambling discussion that goes nowhere.

If there is a problem, open a new, self-contained report that actually
gives details.


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]