New subject: [Bug 37864] When I resize a maximized MDI window it assumes the new size instead of remaining maximized

8 Jan 2015


      https://bugs.winehq.org/show_bug.cgi?id=37864
Bug ID: 37864
           Summary: When I resize a maximized MDI window it assumes the
                    new size instead of remaining maximized
           Product: Wine
           Version: 1.6.2
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
          Assignee: wine-bugs@winehq.org
          Reporter: ryampolsky@yahoo.com
      Distribution: ---
Created attachment 50431
  --> https://bugs.winehq.org/attachment.cgi?id=50431
Screenshot showing a maximized MDI child after resizing 'unmaximizes' it.
My app is a 'smart terminal' that supports multiple sessions in MDI windows. 
The size of the MDI child windows can be changed by the app running on the
server, so at the end of each transaction, if the app has changed the window
dimenensions, I resize the window.  If my MDI window is maximized, this has no
effect on a Windows system (except that if I later unmaximize the MDI child, it
will display at the correct new size).  But on recent WINE builds (Linux and
Mac), when I resize the MDI child, the window assumes the new size, even though
it's techincally in the 'mdi maximized' state (i.e., the MDI buttons are still
there on the menubar.  If I switch between MDI children, they get redrawn
correctly maximized (including the one I just resized).
I coded a workaround in my app where I don't resize the window if it's
maximized, and that seems to work okay under WINE (though I guess the new size
info is getting lost).  In any case, that verifies that the problem is
definitely happening in response to my resize operation.
F.Y.I., my resize operation uses SetWindowPlacement() to change the position
and size of the window - specifically because I don't want it to affect the
window if it's minimized or maximized.  Only if it's in the normal state.
It's been a long time since I wrote this code, but again, it's always worked on
all versions of Windows.  I have a feeling it might have worked a while back in
WINE - though I rarely run maximized, so I may have just recently noticed a bug
that's always been there...
Here's the basic code logic.  SizeWindowForScreenDimentions calls
SetWindowPlacement based on the size calculated for the new row/column grid. 
The code below has the workaround that prevents the problem in WINE.  Also
attached a screenshot showing the unmaximized children with the MDI buttons
still on the menubar.
// If base screen dimensions don't match prior dimensions, resize the window
here.
 // (unless mdi-maximized, in which case, doing this unmaximizes in WINE)
 if (!mdi_maximized) {
   if ((rows != old_rows) || (cols != old_cols)) {
      SizeWindowForScreenDimensions(scr, rows, cols, &resizeable);
   }
 }
// In case window was hidden under an initial popup, show it now.
 ShowWindow(scr->hScreenWnd, SW_SHOW);
-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.

[Bug 37864] New: When I resize a maximized MDI window it assumes the new size instead of remaining maximized