[Mono-bugs] [Bug 79519][Min] Changed - Switching forms is not immediate on slow computers
bugzilla-daemon at bugzilla.ximian.com
bugzilla-daemon at bugzilla.ximian.com
Wed Apr 25 14:32:43 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 rolfkvinge at ya.com.
http://bugzilla.ximian.com/show_bug.cgi?id=79519
--- shadow/79519 2007-04-20 05:55:04.000000000 -0400
+++ shadow/79519.tmp.17356 2007-04-25 14:32:43.000000000 -0400
@@ -1,13 +1,13 @@
Bug#: 79519
Product: Mono: Class Libraries
Version: 1.1
OS: GNU/Linux [Other]
OS Details: Slackware
-Status: NEW
-Resolution:
+Status: RESOLVED
+Resolution: WONTFIX
Severity: Unknown
Priority: Minor
Component: Windows.Forms
AssignedTo: rolfkvinge at ya.com
ReportedBy: kuba.brecka at gmail.com
QAContact: mono-bugs at ximian.com
@@ -90,6 +90,27 @@
------- Additional Comments From toshok at ximian.com 2006-10-21 13:58 -------
Noone has worked on this bug (and might not for a while, as it's
priority is Minor).
That said, I have reproduced it.
+
+------- Additional Comments From rolfkvinge at ya.com 2007-04-25 14:32 -------
+This is showing one of the fundamental differences between Win32 and X:
+Win32 is synchronous and X is asynchronous.
+
+There is no easy way to make X synchronous, we've made a hack that seem
+to mostly work for WM_SHOWWINDOW (that is Show & ShowDialog) - we
+basically keep pumping messages in a special loop until we get the
+WM_SHOWWINDOW.
+
+This won't work for BringToTop, because there's nothing to wait for -
+there may be no consequences at all when calling this method if the form
+is already on the top. A solution might be to have a timeout in the wait,
+however while we wait we'll have to block all messages (otherwise you'll
+be able to click the button again), which will stop the ui from doing
+anything during the wait.
+
+Considering that this only occurs under heavy load or with slow machines,
+the wait time would have to be quite big, having a severe impact on just
+about every winforms app since SetWindowPos is used for quite a few
+things, so I'll close this bug as WONTFIX.
More information about the mono-bugs
mailing list