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

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

bug#6468: closed (Re: bug#6468: A couple of problem related to frame rai


From: Lennart Borgman
Subject: bug#6468: closed (Re: bug#6468: A couple of problem related to frame raising (partly w32))
Date: Thu, 6 Oct 2011 22:39:35 +0200

I prefer to give up. If it is enough to call it rant then I have no
one to eplain to. And I have no time to waste on such answers.


On Thu, Oct 6, 2011 at 22:36, GNU bug Tracking System
<help-debbugs@gnu.org> wrote:
> Your bug report
>
> #6468: A couple of problem related to frame raising (partly w32)
>
> which was filed against the emacs package, has been closed.
>
> The explanation is attached below, along with your original report.
> If you require more details, please reply to 6468@debbugs.gnu.org.
>
> --
> 6468: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6468
> GNU Bug Tracking System
> Contact help-debbugs@gnu.org with problems
>
>
> ---------- Forwarded message ----------
> From: Glenn Morris <rgm@gnu.org>
> To: 6468-done@debbugs.gnu.org
> Date: Thu, 06 Oct 2011 16:35:24 -0400
> Subject: Re: bug#6468: A couple of problem related to frame raising (partly 
> w32)
> 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.
>
>
>
> ---------- Forwarded message ----------
> From: Lennart Borgman <lennart.borgman@gmail.com>
> To: Emacs Bugs <bug-gnu-emacs@gnu.org>
> Date: Sat, 19 Jun 2010 20:23:29 +0200
> Subject: A couple of problem related to frame raising (partly w32)
> 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?
>
>
>
>




reply via email to

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