[debbugs-tracker] bug#16300: closed (24.3.50; 'M-<F10>' doesn't work always)

[GNU bug Tracking System]

Your message dated Sat, 04 Jan 2014 14:43:33 +0100
with message-id <address@hidden>
and subject line Re: bug#16300: 24.3.50; 'M-<F10>' doesn't work always
has caused the debbugs.gnu.org bug report #16300,
regarding 24.3.50; 'M-<F10>' doesn't work always
to be marked as done.

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


-- 
16300: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16300
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> 24.3.50; 'M-<F10>' doesn't work always
>
>
>
>
> Date: 
>
> Mon, 30 Dec 2013 13:02:01 +0100
>
>
>
>
> Recipe from "emacs -Q":
>   M-<F10> M-<F10> M-<F10>
>
> The first time 'M-<F10>' is typed the emacs frame is maximized (OK), the
> second time it is un-maximized (OK), but the third time nothing happens (it
> should be maximized again).
>
>
> In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
>  of 2013-12-29 on LEG570
> Bzr revision: 115804 address@hidden
> Windowing system distributor `Microsoft Corp.', version 6.3.9600
> Configured using:
>  `configure --enable-checking 'CFLAGS=-O0 -g3' CPPFLAGS=-DGLYPH_DEBUG=1'
>
> -- 
> Dani Moncayo
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#16300: 24.3.50; 'M-<F10>' doesn't work always
>
>
>
>
> Date: 
>
> Sat, 04 Jan 2014 14:43:33 +0100
>
>
>
>
> > It seems fixed, indeed.
>
> The current code still doesn't catch all possible transitions.  For
> example, a FULLSCREEN_HEIGHT followed by two M-<F10>s will get you a
> normalized window which is arguable not TRT but catching this without
> introducing additional states seems hardly possible.  Here I do
>
> (defun toggle-full-height ()
>   (interactive)
>   (if (eq (frame-parameter nil 'fullscreen) 'fullheight)
>       (set-frame-parameter nil 'fullscreen 'fullnone)
>     (set-frame-parameter nil 'fullscreen 'fullheight)))
>
> which IMO is the best way to use the FULLHEIGHT feature.
>
> I'll close this bug.
>
> > And BTW, I don't know if it's due to this change, but I can't
> > reproduce the bug #14239 anymore with the current trunk.
>
> The old code used SetWindowPos which according to
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms632611%28v=vs.85%29.aspx
>
> should not be used:
>
>   The coordinates used in a WINDOWPLACEMENT structure should be used
>   only by the GetWindowPlacement and SetWindowPlacement
>   functions. Passing workspace coordinates to functions which expect
>   screen coordinates (such as SetWindowPos) will result in the window
>   appearing in the wrong location. For example, if the taskbar is at the
>   top of the screen, saving window coordinates using GetWindowPlacement
>   and restoring them using SetWindowPos causes the window to appear to
>   "creep" up the screen.
>
> > So it could
> > be closed as well.
>
> Please do that.
>
> martin
>
>
> --- End Message ---