[Mono-bugs] [Bug 81198][Nor] Changed - [Windows] WM_SHOWWINDOW not being called

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Thu Mar 22 13:16:41 EDT 2007


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by monkey at jpobst.com.

http://bugzilla.ximian.com/show_bug.cgi?id=81198

--- shadow/81198	2007-03-20 17:02:52.000000000 -0500
+++ shadow/81198.tmp.6154	2007-03-22 12:16:41.000000000 -0500
@@ -5,18 +5,18 @@
 OS Details: 
 Status: NEW   
 Resolution: 
 Severity: Unknown
 Priority: Normal
 Component: Windows.Forms
-AssignedTo: toshok at ximian.com                            
+AssignedTo: monkey at jpobst.com                            
 ReportedBy: monkey at jpobst.com               
 QAContact: mono-bugs at ximian.com
 TargetMilestone: ---
 URL: 
-Cc: 
+Cc: rolfkvinge at ya.com,toshok at ximian.com
 Summary: [Windows] WM_SHOWWINDOW not being called
 
 In the following test program, WM_SHOWWINDOW never gets called, so the
 button is never made visible.  Is currently breaking PDN on windows.
 
 using System;
@@ -48,6 +48,36 @@
 - When a top-level, overlapped window is created with the WS_MAXIMIZE 
 or WS_MINIMIZE style. 
 (...)
 
 So I suppose the bug is that we can't rely on WM_SHOWWINDOW being 
 sent always...
+
+------- Additional Comments From monkey at jpobst.com  2007-03-22 12:16 -------
+Attaching a patch that fixes the issue on Windows.  However, it breaks
+MDI.  It also may break X11.  (Possible X11 issues: SetWindowState may
+not also set Visible = true like it does on Windows, WM_SHOWWINDOW is
+probably always generated, causing CreateChildren to be called twice.)
+
+Rolf, I would appreciate it if you could massage the patch to work for
+MDI, as you probably have a lot better chance of success than me.  :)
+
+Toshok, can you see what you think of this fix and it's effect on X11?
+
+Patch Summary:
+We no longer send WS_VISIBLE in the CreateWindow function.  Instead we
+set forms visible using SetWindowState (Normal, Max, Min) after they
+are created.  (Matches MS per stacktraces.)
+
+If we set the WindowState to Min or Max, we aren't going to get a
+WM_SHOWWINDOW, so we need to do the important work from WmShowWindow
+manually after we return from SetWindowState.  This work has been
+factored out to CreateChildren.
+
+Also, Form.WindowState has been tweaked.  The issue is that calling
+SetWindowState makes the window visible (on windows at least), so we
+need to track it privately (not using the WM) until the window has
+really been shown.  (The issue was that setting the WindowState in the
+Form's constructor was causing the Form to be shown prematurely.)  The
+shown_raised variable seems to fill this need nicely.
+
+And if I'm completely off-base here, let me know!  :)


More information about the mono-bugs mailing list