GNU bug report logs - #1348
set-frame-width and set-frame-position seem buggy on at least MSWindows

Previous Next

Package: emacs;

Reported by: "Themba Fletcher" <themba <at> shirleymachine.com>

Date: Fri, 14 Nov 2008 22:55:04 UTC

Severity: normal

Done: martin rudalics <rudalics <at> gmx.at>

Bug is archived. No further changes may be made.

Full log


Message #175 received at 1348 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: grischka <grishka <at> gmx.de>
To: martin rudalics <rudalics <at> gmx.at>
Cc: jasonr <at> f2s.com, 1348 <at> debbugs.gnu.org
Subject: Re: bug#1348: set-frame-width and set-frame-position seem buggy on
 at	least MSWindows
Date: Wed, 03 Dec 2008 18:24:54 +0100
martin rudalics wrote:

>  > Actually -100 doesn't mean anything except to let the "async_visible"
>  > flag alone, because otherwise no frame showed at all, for some reason.
> 
> But your patch skips more than just the async_visible assignments.

Saved me one line to type.  Anyway, I found the reason:

     case SIZE_MAXIMIZED:
     case SIZE_RESTORED:
        f->async_visible = 1;

Basically RESTORED or MAXIMIZED don't necessarily mean visible in the
windows sense.  I replaced it with

	f->async_visible = IsWindowVisible(msg.msg.hwnd) ? 1 : 0;

I also replaced w32_read_socket() by a less suspicious looking

	gobble_input (0);

I'm not so into emacs internals to tell whether this is the
finally ideal function to use.  You might know better.

>  >> - if a non-size-related request is in the queue we'd honor it - even it
>  >>   has some of our code re-resize frames?
>  >>
>  > Sure, as always.
> 
> Not really, because the current code doesn't call w32_read_socket until
> input gets unblocked.

Now not sure what you meant.  Probably something not good.
But what?  Size wrong?  Events lost?  Example?

>  >> - if there's another frame we don't care about the
>  >>   record_asynch_buffer_change (); stuff?
>  >>
>  > What buffer change? Resize doesn't change buffers, does it?
> 
> I suppose resizing a frame might do all sorts of nasty things like
> resizing and deleting windows within the resized frame, switching
> buffers, showing another menu-/tool-bar, ...

Only with at least two frames?  Sounds cryptic ;)

> 
> martin
> 

New patch:

########################################
--- w32term-old.c       Mon Dec 01 17:50:28 2008
+++ w32term.c   Wed Dec 03 17:39:21 2008
@@ -4533,7 +4533,7 @@ w32_read_socket (sd, expected, hold_quit

                 case SIZE_MAXIMIZED:
                 case SIZE_RESTORED:
-                  f->async_visible = 1;
+                  f->async_visible = IsWindowVisible(msg.msg.hwnd) ? 1 : 0;
                   f->async_iconified = 0;

                   /* wait_reading_process_output will notice this and update
@@ -5384,6 +5384,7 @@ x_set_offset (f, xoff, yoff, change_grav
                      0, 0,
                      SWP_NOZORDER | SWP_NOSIZE | SWP_NOACTIVATE);
   UNBLOCK_INPUT;
+  gobble_input (0);
 }


@@ -5509,6 +5510,7 @@ x_set_window_size (f, change_gravity, co
 #endif

   UNBLOCK_INPUT;
+  gobble_input (0);
 }
 
 /* Mouse warping.  */
########################################




This bug report was last modified 10 years and 296 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.