Subject: Re: A Proposal (why we should have setBold(true))
From: Eric W. Sink (eric@sourcegear.com)
Date: Wed May 31 2000 - 20:05:36 CDT
>Then there is the modelessizing of find/replace, spelling, options and I
>want to add a new feature that would be great for preparing
>transperencies. A dialog (modeless of course!) with 8 or more
>user-definable colours selected by radio buttons. Put the dialog next the
>window and change colours on the fly. Makes producing coloured
>transperencies a snap! Another non-MS word feature :-)
I'm curious -- which dialogs *should* be modeless?
:-)
I'm cautiously glad that we now have support for modeless dialogs.
Glad? Because most good apps have some dialogs which are modeless,
and the inability to have them would be a Bad Thing.
Cautious? Because I know that modeless dialogs can open up big
cans of worms. Modeless dialogs increase the complexity of the
app. The number of things that can go wrong when a dialog is
modeless is much higher. The rest of the app requires more
attention to detail. When a modeless dialog is up, which parts
of the underlying app are actually active and usable? The answer
is usually different for each app and for each dialog.
I *like* modal dialogs. They're simple to implement, and they
correspond to a style of behavior which is very predictable for
the user.
So, when I saw that modeless dialog support had been added, I was
pleased to have the new capability. When I saw that support starting
to get used, I was glad. But now it seems to be getting used all
over the place, and I'm ready to ask:
Where are we going with this?
Am I the only one who believes that lots of dialogs still deserve
to be modal?
Eric W. Sink, Software Craftsman
SourceGear Corporation
eric@sourcegear.com
This archive was generated by hypermail 2b25 : Wed May 31 2000 - 20:02:03 CDT