bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics <rudalics@gmx.at>]

[-- Attachment #1: Type: text/plain, Size: 595 bytes --]

 >     (modify-frame-parameters
 >      (selected-frame) (list (cons 'font new-font)
 >                 (cons 'scroll-bar-width 6)))))

What happes is that when we ask Windows to change the frame's size, we
don't record the new sizes.  When we ask Windows to change the scrollbar
width, we start again with the old sizes.  I can handle this case by
commenting in some code in w32term.c as in the attached diff.  But that
code was commented our for a reason.  So I don't know what to do.

martin

PS: I don't know why it worked earlier.  In principle, the potential for
this bug was always here.

[-- Attachment #2: w32term.diff --]
[-- Type: text/plain, Size: 997 bytes --]

=== modified file 'src/w32term.c'
--- src/w32term.c	2013-12-07 17:48:52 +0000
+++ src/w32term.c	2013-12-10 14:52:22 +0000
@@ -5726,7 +5726,7 @@
 		       SWP_NOZORDER | SWP_NOMOVE | SWP_NOACTIVATE);
   }
 
-#if 0
+/** #if 0 **/
   /* The following mirrors what is done in xterm.c. It appears to be
      for informing lisp of the new size immediately, while the actual
      resize will happen asynchronously. But on Windows, the menu bar
@@ -5754,7 +5754,7 @@
 
      We pass 1 for DELAY since we can't run Lisp code inside of
      a BLOCK_INPUT.  */
-  change_frame_size (f, width, height, 0, 1, 0, 0);
+  change_frame_size (f, width, height, 0, 1, 0, pixelwise);
   FRAME_PIXEL_WIDTH (f) = pixelwidth;
   FRAME_PIXEL_HEIGHT (f) = pixelheight;
 
@@ -5772,7 +5772,7 @@
      Actually checking whether it is outside is a pain in the neck,
      so don't try--just let the highlighting be done afresh with new size.  */
   cancel_mouse_face (f);
-#endif
+/** #endif **/
 
   unblock_input ();
 }