Modal dialog boxes...

Howdy Ho...
Strangely, I've been hitting this problem. Having been a
java programmer in
the past, I was very surprised when the same problems
exhibited themselves
in .NET.

The problem is namely thus:
When using modal dialogs (custom or system provided), you
can end up with a
situation whereby the modal dialog has not been destroyed or
closed, and is
either invisible or can't be see/rendered - either because
the Z-Order is
stuffed (ie it always renders behind another dialog that is
not modal) or
the dialog is just invisible. Sometimes the user can get
back control doing
alt-tab. More often than not, the application just becomes
stuck.

This creates the following situation - the user can't
interact with your app
any longer. The only way they can close the app is to do a
ctrl-alt-del and
kill the process. The annoying part about this is that it is
indeterminate -
sometimes it occurs, other times it just works. But the end
result is a
stuck application with no way to recover.

Firstly, has anybody experienced this sort of thing and how
did they go
about fixing it? I'm tempted to rip up all my modal dialog
code and just go
modaless - and rely on callbacks and states rather than on
deterministic
'blocking' and handle user input blocking myself. Seems a
bloody awful waste
of time - to have to re-implement modality though.

Secondly, the application I have written is more than just a
few simple
dialogs. I have modal dialogs, which open other modal
dialogs. I'm wandering
if this is this the cause of the problem? I've written a
simple test, and
the behaviour looks ok - but with all things, once it's in a
real app,
things are different.

I've tried ALL available solutions include providing a
suitable/accurate
parent (the top most form), but somehow either .NET or
Window's just can't
render things properly. And the problem seems to occur for
both system
provided dialogs (including MessageBox, OpenFileDialog,
OpenDirectoryDialogs) and my own forms.

--
Cheers,
Jason

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> Firstly, has anybody experienced this sort of thing and
how did they go
> about fixing it? I'm tempted to rip up all my modal
dialog code and just go
> modaless - and rely on callbacks and states rather than
on deterministic
> 'blocking' and handle user input blocking myself. Seems
a bloody awful waste
> of time - to have to re-implement modality though.

I have seen problems with dialog rendering (in Windows
Forms) only in
two situations:
- Multithreaded UIs (without proper use of Control.Invoke)
- Invalid/wrong parent windows specified when showing the
dialogs

Does one of those fit in your situation? I'd guess it is the
first one
- are you using multiple threads?

Fabian

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

On 12/5/07, Jason Nah <jason.nahgmail.com> wrote:
>
> Firstly, has anybody experienced this sort of thing and
how did they go
> about fixing it? I'm tempted to rip up all my modal
dialog code and just go
> modaless - and rely on callbacks and states rather than
on deterministic
> 'blocking' and handle user input blocking myself. Seems
a bloody awful waste
> of time - to have to re-implement modality though.

Other than parenting issues, the only time I've seen this
kind of
problem is when Form.TopMost is set.  A modal dialog whose
owner is
TopMost should also get the TopMost flag -- but I've seen
cases where
it's not set properly.

TopMost is evil and should be avoided in any event .

--
Curt Hagenlocher
curthagenlocher.org

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Hi Fabian,
No... The application I'm writing is not multithreaded
(there are some areas
where it is, but that is working fine)...

I suspect it has something to do with invalid/wrong parent
windows. But I
think it has something to do with having 2 modal dialog
boxes open (ie.
chained)... which I do have. My simplistic testing seems to
indicate this is
ok, but I guess in the real world this isn't advisable.

I was mainly using modality as a focal point - which could I
guess be
achieved using the ownership rather than on modality. Input
blocking would
be a problem. Any ideas?

Modality is rather too simplistically implemented in .NET.
It would seem
that you can't 'transfer' modality which is often the
required behaviour (ie
a modal dialog box, opens another dialog box which is modal)
but not
supported well in either .NET or Java.

On 12/5/07, Fabian Schmied <fabian.schmiedgmx.at> wrote:
>
> > Firstly, has anybody experienced this sort of
thing and how did they go
> > about fixing it? I'm tempted to rip up all my
modal dialog code and just
> go
> > modaless - and rely on callbacks and states rather
than on deterministic
> > 'blocking' and handle user input blocking myself.
Seems a bloody awful
> waste
> > of time - to have to re-implement modality
though.
>
> I have seen problems with dialog rendering (in Windows
Forms) only in
> two situations:
> - Multithreaded UIs (without proper use of
Control.Invoke)
> - Invalid/wrong parent windows specified when showing
the dialogs
>
> Does one of those fit in your situation? I'd guess it
is the first one
> - are you using multiple threads?
>
> Fabian
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>



--
Cheers,
Jason

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Hi Frans,

On 12/5/07, Frans Bouma <perseus3xs4all.nl> wrote:
>
> I've not seen this behavior before, but here are some
pointers which might
> help:
> 1) always make the application's main form the PARENT
of the modal dialog.
> Don't ever open a modal dialog with the desktop as
parent for example.


So if I have the following scenario

Window 1 --opens---> Window 2 ----opens---> Window3

And Window3 is a modal dialog box, then the parent is
Window1 and not
Window2???

2) in the properties of a dialog, you can specify to show
the dialog in the
> taskbar. It might be a good idea to switch this on. The
modal dialog will
> get
> its own button in the taskbar and if the dialog gets
hidden or minimized,
> the
> user can select it again by clicking the button in the
taskbar


This would seem like an awkward fix. My assumption is that
.NET should know
to make the modal dialog's Z-Order ahead of any other
application window.
That would seem really easy to implement but they haven't
done it that way
(hence a modal dialog could be behind other windows)...
again, strange.

3) never ever open 2 modal dialogs at once. The concept of a
modal dialog is
> to make sure the user fulfills the dialog before
continuing with the
> application. If you need to open more than one,
consider other layouts of
> the
> UI.


This I am doing. Which is what I'm thinking of reversing.
But this would
also seem rather restrictive. Imagine you had a modal dialog
and from that
dialog you wanted to show a message box. That's 2 modal
dialogs at once. So
if you have a custom modal dialog you can't use any of the
system provided
modal dialog boxes??

4) modal dialogs don't need to have their topmost flag set
to true. I have
> found that setting that flag gives odd results.
>
>         FB
>
> > Strangely, I've been hitting this problem. Having
been a java programmer
> in
> > the past, I was very surprised when the same
problems exhibited
> themselves
> > in .NET.
> >
> > The problem is namely thus:
> > When using modal dialogs (custom or system
provided), you can end up
> with a
> > situation whereby the modal dialog has not been
destroyed or closed, and
> is
> > either invisible or can't be see/rendered - either
because the Z-Order
> is
> > stuffed (ie it always renders behind another
dialog that is not modal)
> or
> > the dialog is just invisible. Sometimes the user
can get back control
> doing
> > alt-tab. More often than not, the application just
becomes stuck.
> >
> > This creates the following situation - the user
can't interact with your
> app
> > any longer. The only way they can close the app is
to do a ctrl-alt-del
> and
> > kill the process. The annoying part about this is
that it is
> indeterminate -
> > sometimes it occurs, other times it just works.
But the end result is a
> > stuck application with no way to recover.
> >
> > Firstly, has anybody experienced this sort of
thing and how did they go
> > about fixing it? I'm tempted to rip up all my
modal dialog code and just
> go
> > modaless - and rely on callbacks and states rather
than on deterministic
> > 'blocking' and handle user input blocking myself.
Seems a bloody awful
> waste
> > of time - to have to re-implement modality
though.
> >
> > Secondly, the application I have written is more
than just a few simple
> > dialogs. I have modal dialogs, which open other
modal dialogs. I'm
> wandering
> > if this is this the cause of the problem? I've
written a simple test,
> and
> > the behaviour looks ok - but with all things, once
it's in a real app,
> > things are different.
> >
> > I've tried ALL available solutions include
providing a suitable/accurate
> > parent (the top most form), but somehow either
.NET or Window's just
> can't
> > render things properly. And the problem seems to
occur for both system
> > provided dialogs (including MessageBox,
OpenFileDialog,
> > OpenDirectoryDialogs) and my own forms.
> >
> > --
> > Cheers,
> > Jason
> >
> > ===================================
> > This list is hosted by DevelopMentorR  http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> http://discuss.develop.com

>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>



--
Cheers,
Jason

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Hi Curt,
I don't use TopMost at all. I've used it before and you are
right, it's not
as one would expect. Far better to use Owned was what I
found.

On 12/6/07, Curt Hagenlocher <curthagenlocher.org> wrote:
>
> On 12/5/07, Jason Nah <jason.nahgmail.com> wrote:
> >
> > Firstly, has anybody experienced this sort of
thing and how did they go
> > about fixing it? I'm tempted to rip up all my
modal dialog code and just
> go
> > modaless - and rely on callbacks and states rather
than on deterministic
> > 'blocking' and handle user input blocking myself.
Seems a bloody awful
> waste
> > of time - to have to re-implement modality
though.
>
> Other than parenting issues, the only time I've seen
this kind of
> problem is when Form.TopMost is set.  A modal dialog
whose owner is
> TopMost should also get the TopMost flag -- but I've
seen cases where
> it's not set properly.
>
> TopMost is evil and should be avoided in any event .
>
> --
> Curt Hagenlocher
> curthagenlocher.org
>
> ===================================
> This list is hosted by DevelopMentor(R)  http://www.develop.com
>
> View archives and manage your subscription(s) at
> http://discuss.develop.com

>



--
Cheers,
Jason

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> On 12/5/07, Frans Bouma <perseus3xs4all.nl> wrote:
> >
> > I've not seen this behavior before, but here are
some pointers which might
> > help:
> > 1) always make the application's main form the
PARENT of the modal dialog.
> > Don't ever open a modal dialog with the desktop as
parent for example.
>
> So if I have the following scenario
>
> Window 1 --opens---> Window 2 ----opens--->
Window3
>
> And Window3 is a modal dialog box, then the parent is
Window1 and not
> Window2???

        Parent of window3 is window2, as window2 opens
window3.

> 2) in the properties of a dialog, you can specify to
show the dialog in the
> > taskbar. It might be a good idea to switch this
on. The modal dialog will
> > get
> > its own button in the taskbar and if the dialog
gets hidden or minimized,
> > the
> > user can select it again by clicking the button in
the taskbar
>
> This would seem like an awkward fix. My assumption is
that .NET should know
> to make the modal dialog's Z-Order ahead of any other
application window.
> That would seem really easy to implement but they
haven't done it that way
> (hence a modal dialog could be behind other windows)...
again, strange.

        It's windows who controls the Z-order, not .net 

        The button in the taskbar isn't always awkward. For
example if you
spawn a dialog which starts a process and the dialog is
rather big, so the
user spends say 2 minutes in it, it could be a good idea to
have the taskbar
button.

> 3) never ever open 2 modal dialogs at once. The concept
of a modal dialog is
> > to make sure the user fulfills the dialog before
continuing with the
> > application. If you need to open more than one,
consider other layouts of
> > the
> > UI.
>
>
> This I am doing. Which is what I'm thinking of
reversing. But this would
> also seem rather restrictive. Imagine you had a modal
dialog and from that
> dialog you wanted to show a message box. That's 2 modal
dialogs at once. So
> if you have a custom modal dialog you can't use any of
the system provided
> modal dialog boxes??

        The thing is that if you have 2 modal dialogs, who's
first? The point
of a modal dialog is that the user can't go somewhere else.

        Anyway, you might want to look into docking. So an
MDI kind of
approach where you dock windows into a main window with tabs
and sliding
panels.

                FB

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> No... The application I'm writing is not multithreaded
(there are some areas
> where it is, but that is working fine)...

Hm, a pity, that would've explained it so nicely 

On the other hand, since you're probably using .NET 2.0,
this kind of
errors is usually detected by Windows.Forms anyway. But just
to make
completely sure because you say there are some areas where
it is
multi-threaded: Does your application never access a GUI
control or
window from a different thread than the UI thread (which is
usually
the one calling Application.Run)?

> I suspect it has something to do with invalid/wrong
parent windows. But I
> think it has something to do with having 2 modal dialog
boxes open (ie.
> chained)... which I do have. My simplistic testing
seems to indicate this is
> ok, but I guess in the real world this isn't
advisable.

This is actually supported quite fine by Windows (and thus
by .NET;
Windows.Forms uses Windows for all that Z-Order and
modality
handling). You can use the tool Spy++ that comes with Visual
Studio to
better diagnose issues like this. Try to reproduce the
situation, then
fire up Spy++, find your dialog windows (either in the tree
or using
the window finder tools), and inspect their properties. Look
at the
styles (compare them with modal dialogs in other
applications and look
up their meaning in the MSDN docs) and the related windows
(especially
parent and owner). Maybe you find out something that way.
You could
also ask at a Win32-related newsgroup or forum whether there
are any
known issues with Win32 dialog windows that would cause the
behavior
you are seeing.

> I was mainly using modality as a focal point - which
could I guess be
> achieved using the ownership rather than on modality.
Input blocking would
> be a problem. Any ideas?

For input blocking, you could also disable the window. But I
still
know that what you want is possible in Windows and .NET, so
I'd rather
try to find the problem. But maybe you just want a quick
fix. 

Fabian

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

> Strangely, I've been hitting this problem. Having been
a java programmer in
> the past, I was very surprised when the same problems
exhibited themselves
> in .NET.

Do you have a ErrorProvider on one of the forms?  Check this
fix in
SP1 http://suppor
t.microsoft.com/kb/920923/

-- 
"He uses statistics as a drunken man uses lamp-postsā€¦
for support
rather than illumination." Andrew Lang

Marc C. Brooks
http://musingmarc.blog
spot.com

Nope. The application is a .NET 1.1 application.
Incidentally, I've found that using Owner is a far better
way to go for most
dialogs and for the ones that happen to really be modal (ie.
they are
usually end screens that don't spawn more windows) to then
use modal logic.

I've since rewritten that area and things seem to be working
smoothly.

Cheers,
Jason

On 12/13/07, Marc Brooks <idisposablegmail.com> wrote:
>
> > Strangely, I've been hitting this problem. Having
been a java programmer
> in
> > the past, I was very surprised when the same
problems exhibited
> themselves
> > in .NET.
>
> Do you have a ErrorProvider on one of the forms?  Check
this fix in
> SP1 http://suppor
t.microsoft.com/kb/920923/
>
> --
> "He uses statistics as a drunken man uses
lamp-posts… for support
> rather than illumination." Andrew Lang
>
> Marc C. Brooks
> http://musingmarc.blog
spot.com
>



-- 
Cheers,
Jason

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com