Board index » cppbuilder » MDI or NOT

MDI or NOT


2003-10-02 12:06:50 AM
cppbuilder103
I have ambitous plans for a new GUI - lots of windows and docking.
Should I make it MDI or not?
Personally, I prefer using MDI apps - for instance, I prefer the
windows in VC++ 6 over those in BCB.
But I there are more problems to program for MDI (as I understand it).
For instance, one cannot hide MDI child windows, modal dialogs are not
MDI children.
What do you guys prefer? What kind of feedback do you get from users?
Am I the only one who prefers MDI?
Thanks!
/sten
/sten
---
For direct email, remove _ and X.
 
 

Re:MDI or NOT

"Sten Larsson" < XXXX@XXXXX.COM >wrote in message
Quote
I have ambitous plans for a new GUI - lots of windows and docking.
Should I make it MDI or not?


Personally, I prefer using MDI apps - for instance, I prefer the
windows in VC++ 6 over those in BCB.

But I there are more problems to program for MDI (as I understand it).
For instance, one cannot hide MDI child windows, modal dialogs are not
MDI children.

What do you guys prefer? What kind of feedback do you get from users?
Am I the only one who prefers MDI?
There are some known bugs in the VCL MDI implementation (at least in BCB5 --
I'm not sure if they were fixed in BCB6), and some of those bugs manifest
themselves in different ways on different versions of Windows. There are
fixes available, but as you may know, you cannot re-build the VCL libraries,
which forces you to patch the fixed VCL source into your application, which
subsequently prevents you from using the VCL packages (you must use the
static VCL libraries, and that, of course, greatly increases the size of
your EXE).
You might consider implementing MDI-like behavior instead of actually using
MDI. I can't tell you exactly how to do that, but there are numerous
messages in the BCB newsgroup archives that offer alternatives to MDI.
- Dennis
 

Re:MDI or NOT

Sten Larsson < XXXX@XXXXX.COM >wrote in
Quote
What do you guys prefer? What kind of feedback do you get from users?
Am I the only one who prefers MDI?
Ask yourself what it is about MDI that you really like, that makes you
prefer it to an SDI-like solution. Then take another look at your problem
and see if it is a good match.
I like MDI when I have a lot of open documents that I can resize and
compare in a manner of my choosing. This also implies that I would not
expect to (routinely) fit the entire document onto screen at one time.
In all other cases I find MDI either confusing or irritating, and often
both!
Generally, our applications are SDI, with as few pop-ups as possible. That
seems to give the user the feeling of being in control, which is important
if they are going to relax and be comfortable with the software.
We have used MDI on the rare occasion it proved appropriate for us, but
most of our screens are reporting very specific data designed to fit
exactly within the available screen estate, so maybe we're not the best
comparison <g>
AlisdairM
 

{smallsort}

Re:MDI or NOT

Sten Larsson < XXXX@XXXXX.COM >wrote
Quote
I have ambitous plans for a new GUI - lots of windows and docking.
Should I make it MDI or not?
Our app was MDI for years, but I gave up on it partly because of MDI bugs
in BCB5. However, I got some inspiration looking at many of the very
interesting new interfaces for Windows apps. Our app has a variety of types
of documents which differ a lot from each other. I ended up choosing
basically a tabbed main Window with some customized behaviour related to
the document types. Too much to go into here, but we use frames on tabs,
with a frame base class and hierarchy for different document classes. I
decided on that approach after working with MS FrontPage 2002, which also
uses a tabbed interface for multiple documents, similar to the Builder IDE.
I'm not a bit sorry to have left MDI behind, and not one of our several
hundred users has complained or even commented on the change.
JM
 

Re:MDI or NOT

"Jim Melsom" < XXXX@XXXXX.COM >wrote in message
Quote
Sten Larsson < XXXX@XXXXX.COM >wrote
>I have ambitous plans for a new GUI - lots of windows and docking.
>Should I make it MDI or not?

Our app was MDI for years, but I gave up on it partly because of MDI bugs
in BCB5. However, I got some inspiration looking at many of the very
interesting new interfaces for Windows apps. Our app has a variety of
types
of documents which differ a lot from each other. I ended up choosing
basically a tabbed main Window with some customized behaviour related to
the document types. Too much to go into here, but we use frames on tabs,
with a frame base class and hierarchy for different document classes. I
decided on that approach after working with MS FrontPage 2002, which also
uses a tabbed interface for multiple documents, similar to the Builder
IDE.
I'm not a bit sorry to have left MDI behind, and not one of our several
hundred users has complained or even commented on the change.
I am doing something similar in an application I am developing now. I have
a TPageControl component on my main form. The page control is aligned with
'alClient', so it takes up the entire client area of the main form (minus
the menu, tool bar and status bar). For each "view" I need in my
application, I create a separate form, and each form is then "embedded" on a
page (TTabSheet) of the page control. Although it's not something I need in
my application, if I want to, I can have multiple pages (tabs) with the same
"view" (like you can with MDI). The only drawback (if you can call it a
drawback) is that only one "view" is visible at any one time (you can't have
tiled views, for example, like you can with MDI).
To make this work, I have a base class, "TBaseView", from which all of my
"views" derive. The base class handles embedding the form in the page
control and provides MDI-style menu merging. And since I wrote the menu
merge code, I can merge same-name top-level menus into a single top-level
menu -- something that is impossible with MDI. The only thing I have to do
in the main form is add the views to the page control at runtime, and send
Activate/Deactivate messages to the views (which are required to allow menu
merging).
This technique works really well, and what's especially great about it is
the fact that whenever I need a new "view", I just create a form that
descends from TBaseView, add my components, menu items (if any), etc, (just
like a regular form), and I'm done. All the functionality for that
particular view is then localized in the form's unit, which reduces coupling
and prevents polluting the main form with a bunch of code for multiple,
heterogenous tab sheets in the page control.
Although it took some time and thought to get right, now that it's all done,
it seems pretty simple. I'd be happy to provide sample code for anyone
wanting to do something like this, or screenshots if it's not clear from the
description what it looks like.
- Dennis