[Mono-winforms-list] Form.ShowDialog() - blocking behaviour different from MS .NET

[Marek Vokac]

Hello, I have an application that in GUI behaviour is similar to the one
mentioned by AutoLyrix: It has no main Form, but only a NotifyIcon. This
application reacts to outside events and sometimes needs to show a small
GUI. Multiple events are handled simultaneously, each by its own Thread.

 

Now, the way we have implemented it on native .Net is by setting up the form
to be shown and using ShowDialog(). On the native platform, that causes the
thread to process messages related to the form, but otherwise "block" in the
sense that the ShowDialog() call returns only when some code sets
DialogResult on the form.

 

In the meantime, a worker thread spawned before ShowDialog does some work
(like downloading a file) and displays progress on the form (obviously via
Invoke calls to correctly switch threads). At some point, the work is done,
the worker thread sets DialogResult and the "main" thread returns from
ShowDialog().

 

This behaviour, where ShowDialog "blocks" its calling thread but allows
normal message processing for the Form - for multiple parallel threads -  is
ideally suited to our needs. However, on Mono (I have tried both on Windows
XP and Debian), ShowDialog seems to behave differently, leading to what
amounts to an application-wide block. So I cannot have multiple parallel
threads each in its own ShowDialog - the last one called has to close first,
and until it returns no events are processed by the other forms.

 

If this is unclear or too long-winded I can post a minimal example that
demonstrates the difference. We tried getting around it in various ways with
little success. The closest we got was to exchange the ShowDialog for
.Show() followed by a tight loop calling DoEvents and Sleep(1). However,
this is not reliable (if too many events pile up things freeze), and from a
design standpoint it looks exceptionally ugly.

 

I would like to hear if anyone has thoughts on whether this difference is by
design, maybe caused by the underlying systems, or what. and whether this is
in some way solvable. A solution that works is better than one that is
elegant; having both would be the best of both worlds :-).

 

We have followed Mono and WinForms for a while and find it to be an
impressive effort. Surely there are way fewer people working on it than on
the Microsoft side, yet the results rival those of the giant. Well done, and
a nice illustration of the power of small, dedicated groups.

 

Best regards,

Marek Vokac

Chief Architect

SuperOffice ASA, Norway

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-winforms-list/attachments/20080206/a7c5a9b1/attachment-0001.html