Re: [Q] New frames not displayed correctly if buffer tabs off

--On Friday, March 21, 2003 8:59 AM +0100 "Michael Sperber [Mr. 
Preprocessor]" <[email protected]> wrote:

>>>>>> "Mike" == Mike Alexander <[email protected]> writes:
>
> Mike> --On Thursday, March 20, 2003 5:54 PM +0900 "Stephen J. Turnbull"
> Mike> <[email protected]> wrote:
>
>
> Mike> >
> Mike> How about 21.5?  Has it been committed there?
> Mike> >
>>> Not yet.  Note that Mike Sperber has changed the window config code.
>>> If you are not familiar with his changes there, I don't think it's a
>>> good idea to commit this.
>
> Mike> But I think it was those changes that caused this bug to appear
> Mike> in the first place.  Not that there is a bug in Mike's changes,
> Mike> but rather that those changes exposed a pre-existing bug in the
> Mike> Windows interface code.  I haven't tracked back exactly when the
> Mike> bug first appeared but it was about the time that Mike's changes
> Mike> were made.  I'm generally familiar with those changes, although I
> Mike> haven't studied them in detail, and think that this patch is
> Mike> consistent with them.

>
> It should be.  But I'm curious why it should have anything to do with
> the window-config changes---they use `set-frame-pixel-size.'  Is there
> a code path from there to your patch?

No, it's not that.  What's happening is that after a call to make-frame 
xemacs gets into redisplay_frame for the new frame with both size_slipped 
and size_change_pending still set.  If buffer tabs are on then this doesn't 
happen since the process of adjusting the frame for the gutter processes 
the size change.  Since size_slipped is on, redisplay_frame calls 
adjust_frame_size which, on Windows, eventually gets into 
mswindows_set_frame_size.  Without the call to change_frame_size that I 
added the frame size never gets processed and the size of the root window 
is left very tiny with most of the frame not included in any window.

My guess is that before your changes there was something else happening 
that caused the frame size to be processed so the bug in the Windows code 
didn't matter.  This no longer happens (and it probably isn't worth while 
figuring out why) so the bug was exposed.

Mike Alexander                <mailto:[email protected]>
Arbortext, Inc.               +1-734-997-0200