Board index » cppbuilder » moving an SDI application into mixed (MDI+SDI) mode -- how to?

moving an SDI application into mixed (MDI+SDI) mode -- how to?


2005-03-04 01:28:43 AM
cppbuilder73
Borland's wizards create MDI and SDI as two
distinct kinds of apps. But looking at the
TForm properties, it appears MDI and SDI are
properties of the form, not the application.
This suggests that it is possible to mix MDI
with SDI in the same application.
For a design app, which can have many forms open at once,
this sounds like an ideal way to reduce screen clutter:
corral related windows into a single MDI window,
as the window's children.
But is it possible to turn an SDI app into a mixed
SDI+MDI app? With Builder 3?
What are the constraints on using SDI and MDI in the same
application? From other sources, it looks like:
1) If MDI is used at all, then the app must be an MDI app,
meaning the main form is an MDI parent, and has MDI
children. Is this correct?
2)An SDI app can be converted into an MDI app.
One must change (at design time)
the main form's FormStyle to make it an MDI parent, and
make sure that each new MDI child window knows its parent.
But is that _sufficient_? Are MDI apps different in other
ways that I'd have to address?
3) An MDI app can have any number of top-level MDI windows,
each with its own children. But do they all have to be
the same _type_ of window? (E.g., if the main form is of
type TFormMdi1, can other top-level forms be of type
TFormMdi2, TFormMdi3, etc. _not_ derived from TFormMdi1?)
4) An MDI app can use SDI windows, too, such as modal and non-
modal dialog boxes, with no extra effort. Is this correct?
-Phil
 
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Phil Colbert wrote:
Quote
it appears MDI and SDI are
properties of the form, not the application.
Both is not true. MDI/SDI is just an idea to have a Multiple
Document Interface or a Single Document Interface.
Quote
This suggests that it is possible to mix MDI
with SDI in the same application.
You can mix fsMDIForm with fsMDIChild, fsNormal and fsStayonTop.
Quote
But is it possible to turn an SDI app into a mixed
SDI+MDI app? With Builder 3?
Of course. Just make it as yoy wish. But I think that you
first have to tell why you consider your app to be a SDI
app now. And how it is build up using more than one window ?
Quote
1) If MDI is used at all, then the app must be an MDI app,
meaning the main form is an MDI parent, and has MDI
children. Is this correct?
No. fsMDIForm can have fsMCIChild children but also fsNormal and
fsStayOnTop.
Quote
2)An SDI app can be converted into an MDI app.
One must change (at design time)
the main form's FormStyle to make it an MDI parent, and
make sure that each new MDI child window knows its parent.
A fsMDIChild will know its Parent without you having to
do anything for that.
Quote
3) An MDI app can have any number of top-level MDI windows,
"top-level MDI windows" ? I only know fsMDIChild.
Quote
each with its own children.
What type are those children ? They cannot be fsMDIChild.
Quote
But do they all have to be
the same _type_ of window? (E.g., if the main form is of
type TFormMdi1, can other top-level forms be of type
TFormMdi2, TFormMdi3, etc. _not_ derived from TFormMdi1?)
What is a toplevel form. But that does not matter as all
children can be of a different class.
Quote
4) An MDI app can use SDI windows,
Impossible. As MDI/SDI is the type of application.
Please explain in terms of FormStyle like I did.
Hans.
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Hans Galema < XXXX@XXXXX.COM >wrote:
Quote
Phil Colbert wrote:

>it appears MDI and SDI are
>properties of the form, not the application.

Both is not true. MDI/SDI is just an idea to have a Multiple
Document Interface or a Single Document Interface.
There's much more than an _idea_ here. Windows documentation
and Builder documentation clearly describe _implementation_
details and implementation _constraints_ (e.g., the main form
of an MDI application _must_ be of style fsMDIForm, and its
child forms must be of style fsMDIChild).
The Builder New Application wizard clearly distinguishes
between MDI _applications_ and non-MDI (SDI) _applications_.
This would not be possible if it was "just an idea."
Quote
>This suggests that it is possible to mix MDI
>with SDI in the same application.

You can mix fsMDIForm with fsMDIChild, fsNormal and fsStayonTop.
I'm sure that's true. Yet there are constraints.
(I mentioned two of them above.) A few constraints
are documented. Are they the _only_ _known_ constraints?
A good design begins with knowing the full set of
constraints. That's why I'm posting here: to find out
_whether_ there are any other constraints on the use
of each FormStyle, and if there are, _what_ they are.
Quote
>But is it possible to turn an SDI app into a mixed
>SDI+MDI app? With Builder 3?

Of course. Just make it as yoy wish. But I think that you
first have to tell why you consider your app to be a SDI
app now.
Because when I started the project, years and years ago,
the Wizard made me choose whether the project was to
be MDI or not. I said "not."
And if it's not MDI, then the only other choice,
as far as I know, is SDI.
Certainly there are no forms of style fsMDIForm or
fsMDIChild in this application.
Quote
And how it is build up using more than one window ?
In the program's main menu, the user chooses what kind of
object he wishes to edit. This creates an SDI window,
on the desktop, listing all objects of that type. This
window is non-modal. While editing or creating new
objects, the user can return to the list window, or to
any object's window, as he sees fit. Perhaps to copy
from one window and paste into another.
All of these windows are of style fsNormal. That makes
them all SDI windows, doesn't it? And if the app consists
solely of SDI windows, doesn't that make it an SDI app?
Quote
>1) If MDI is used at all, then the app must be an MDI app,
>meaning the main form is an MDI parent, and has MDI
>children. Is this correct?

No. fsMDIForm can have fsMCIChild children but also fsNormal and
fsStayOnTop.
As _child_ forms for fsMDIForm? That possibility is not
mentioned in any documentation I've seen. I'd like to
understand how and why you might use such a combination.
Let's assume you have an fsMDIForm, and it has fsMDIChild
children. Now you want to add an fsNormal form.
Why would you make it a child of this fsMDIForm, instead
of just an ordinary dialog window (modal or otherwise)?
Quote
>2)An SDI app can be converted into an MDI app.
>One must change (at design time)
>the main form's FormStyle to make it an MDI parent, and
>make sure that each new MDI child window knows its parent.

A fsMDIChild will know its Parent without you having to
do anything for that.
Really? Let's suppose that my main form is an fsMDIForm,
and that it creates two more fsMDIForms (Owner=NULL).
(This is suggested by a Microsoft document.)
How will my fsMDIChild forms know which of these three
top-level fsMDIForms is its MDIParent?
Quote
>3) An MDI app can have any number of top-level MDI windows,

"top-level MDI windows" ? I only know fsMDIChild.
From the Windows SDK:
"top-level window: A window that has no parent window."
"Top-level" is the terminology used by a Microsoft document.
The document attempts to explain why a fsMDIChild
cannot have fsMDIChildren of its own. It goes on to
describe an application that has several fsMDIForm windows
all open at the same time, all being top-level windows.
Quote
>each with its own children.

What type are those children ? They cannot be fsMDIChild.
As I understand it, if they are MDI children of an fsMDIForm,
then they _must_ be of style fsMDIChild. But I'd be happy
to look at a working counter-example, or even read about
one. Do you know where I can find one?
Quote
>But do they all have to be
>the same _type_ of window? (E.g., if the main form is of
>type TFormMdi1, can other top-level forms be of type
>TFormMdi2, TFormMdi3, etc. _not_ derived from TFormMdi1?)

What is a toplevel form.
From the Windows SDK:
"top-level window: A window that has no parent window."
Quote
But that does not matter as all
children can be of a different class.
I think you misunderstood my question. I was asking about
mixing types of top-level windows. Microsoft's example
says that you can have multiple top-level windows, all MDI
(i.e., fsMDIForm), but it does not say that they can be
of different types (Window classes).
Quote
>4) An MDI app can use SDI windows,

Impossible. As MDI/SDI is the type of application.
Er, I thought you said MDI/SDI was "just an idea"? ;-)
It seems to me that an MDI app ought to be able to use
ordinary dialog box windows, on occasion, for input.
Of course, these dialogs are of style fsNormal.
That makes them SDI windows, doesn't it?
You yourself said above,
Quote
You can mix fsMDIForm with fsMDIChild, fsNormal and fsStayonTop.
The latter two styles are not MDI, but SDI.
So, am I missing something?
Quote
Please explain in terms of FormStyle like I did.
I hope I have.
Quote
Hans.
Thank you for your time and attention, Hans. It's clear
that you know much more about this than I do. Thank you
for being willing to help clear up my confusion.
-Phil
 

{smallsort}

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

OOPS.
"Owner=NULL" should have been "Parent=NULL".
"MDIParent" should have been "Parent".
To wit:
Quote
>2)An SDI app can be converted into an MDI app.
>One must change (at design time)
>the main form's FormStyle to make it an MDI parent, and
>make sure that each new MDI child window knows its parent.

A fsMDIChild will know its Parent without you having to
do anything for that.
Wow! Let's suppose that my main form is an fsMDIForm,
and that it creates two more fsMDIForms (Parent=NULL).
(This is suggested by a Microsoft document.) Later, when
I create a fsMDIChild form, I would expect I would
have to set its Parent property to one of these forms.
But if you're right, I don't have to set its Parent
property at all.
If I _don't_ set its Parent property, which Parent does it
assume? The main form?
-Phil
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Phil Colbert wrote:
Quote
Wow! Let's suppose that my main form is an fsMDIForm,
and that it creates two more fsMDIForms (Parent=NULL).
That is impossible to begin with. There can only be one form
of FormStyle fsMDIForm and that should be the mainform.
Quote
(This is suggested by a Microsoft document.)
Really ?
Quote
Later, when
I create a fsMDIChild form, I would expect I would
have to set its Parent property to one of these forms.
That would be logic then yes. But in reality there is only
one parent. And assigning goes automatically.
Hans.
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Phil Colbert wrote:
Quote
There's much more than an _idea_ here. Windows documentation
and Builder documentation clearly describe _implementation_
details and implementation _constraints_ (e.g., the main form
of an MDI application _must_ be of style fsMDIForm, and its
child forms must be of style fsMDIChild).
Yes. That is the idea behind it.
Quote
The Builder New Application wizard clearly distinguishes
between MDI _applications_ and non-MDI (SDI) _applications_.
SDI is then just non-MDI.
Quote
>>This suggests that it is possible to mix MDI
>>with SDI in the same application.
Well now we first should know what you mean with that. As said:
the application is of type MDI or SDI. So then you cannot mix.
But of course you can add some fsNormal windows to a MDI app.
Quote
A few constraints
are documented. Are they the _only_ _known_ constraints?
You did not mention practical constraints for the buildup
of several windows to one app.
Quote
A good design begins with knowing the full set of
constraints. That's why I'm posting here: to find out
_whether_ there are any other constraints on the use
of each FormStyle, and if there are, _what_ they are.
Other then that there can be only one fsMDIForm and that
you should create some fsMDICild forms to really call your
app a MDI application. No. And then you can add lots
of fsNormal (not a good idea exept for modal) and fsStayOnTop
windows. If you would assign the fsMDIForm as Parent of a
fsStayOnTop window then it would nearly behave as a fsMDIChild.
But that is not a good idea to follow.
Quote
Certainly there are no forms of style fsMDIForm or
fsMDIChild in this application.
At designtime you can change the formstyle.
Quote
In the program's main menu, the user chooses what kind of
object he wishes to edit. This creates an SDI window,
on the desktop,
Heh ? That is not my idea of an SDI application. An SDI
application does NOT create extra windows. It has only one
mainwindow. If it is a textediter it can only handle one
text(file). If you want to edit two files then two instances
of the applications will be started. Of course it can have
a lot of dialogs and other helpwindows.
Quote
All of these windows are of style fsNormal. That makes
them all SDI windows, doesn't it?
No. A window is never SDI.
Quote
Let's assume you have an fsMDIForm, and it has fsMDIChild
children. Now you want to add an fsNormal form.
Why would you make it a child of this fsMDIForm,
If you mean that I would assign the mainform as its parent ?
No I would not do that. I would just create it and let it
float around.
Quote
From the Windows SDK:
"top-level window: A window that has no parent window."
The document attempts to explain why a fsMDIChild
cannot have fsMDIChildren of its own. It goes on to
describe an application that has several fsMDIForm windows
all open at the same time, all being top-level windows.
Wel that would be nonsence then as you first said that a
top-level window has no parent. The Parent of a fsMDIChild
is the single fsMDIForm (as far as I know). So a fsMDIChild
is no top-level.
Hans.
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Hans Galema wrote:
Quote
>The document attempts to explain why a fsMDIChild
>cannot have fsMDIChildren of its own. It goes on to
>describe an application that has several fsMDIForm windows
>all open at the same time, all being top-level windows.
Wel that would be nonsence then as you first said that a
top-level window has no parent. The Parent of a fsMDIChild
is the single fsMDIForm (as far as I know). So a fsMDIChild
is no top-level.
Sorry. That reply is not to the point. I misread.
Will try again:
Quote
>The document attempts to explain why a fsMDIChild
>cannot have fsMDIChildren of its own.
Yes. That is not possible.
Quote
>It goes on to
>describe an application that has several fsMDIForm windows
>all open at the same time, all being top-level windows.
There can only be one fsMDIForm in a C++Builder application
and that should be the mainform.
Hans.
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Hans Galema < XXXX@XXXXX.COM >wrote:
Quote
>All of these windows are of style fsNormal. That makes
>them all SDI windows, doesn't it?

No. A window is never SDI.
Sorry. Applications can be either MDI or SDI. I thought
it would be the same for windows. Especially since this
is expressed through a _form_ style (not an _application_
style).
What term should I use to describe a non-MDI window?
-Phil
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Hans Galema < XXXX@XXXXX.COM >wrote:
Quote
Phil Colbert wrote:

>Wow! Let's suppose that my main form is an fsMDIForm,
>and that it creates two more fsMDIForms (Parent=NULL).

That is impossible to begin with. There can only be one form
of FormStyle fsMDIForm and that should be the mainform.

>(This is suggested by a Microsoft document.)

Really ?
Yes. It's in the Microsoft SDK help files shipped with every
copy of Builder. The document is titled
Windows Does Not Support Nested MDI Client Windows
You can find it in the Win32 Developer's References. Click
the Index button, then the Find tab. Enter "MDI" in Field 1.
In Field 3, scroll down to very end. It's a page or two
above that.
Microsoft's
Windows Does Not Support Nested MDI Client Windows
is what gave me the idea of using multiple MDI Forms,
one per group of related MDI Client Windows, in the same
application. Microsoft explicitly says you _can_ do it.
Of course, depending on how the application's message loop
is written, these forms might have to be all of the same
window class, i.e., C++ type.
And if the _VCL_ doesn't support multiple fsMDIForms,
all open at the same time,
then I might as well forget about it.
-Phil
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Hans Galema < XXXX@XXXXX.COM >wrote:
Quote
There can only be one fsMDIForm in a C++Builder application
and that should be the mainform.
That's too bad. Microsoft's
Windows Does Not Support Nested MDI Client Windows
(mentioned in a response I posted today)
shows that _Windows_ supports multiple fsMDIForms open and
active at the same time.
The idea has obvious utility.
For example, if you have three groups of closely-related
windows, and five windows in each group, then
you could turn each group into its own fsMDIForm. It would
make conceptual as well as visual sense. It would also
keep users from mixing up unrelated windows, and thinking
that they were related.
But if the VCL doesn't support it,
then we might as well forget about it.
I'll have to think about other
visual methods of organizing these things.
-Phil
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Phil Colbert wrote:
Quote
Sorry. Applications can be either MDI or SDI. I thought
it would be the same for windows. Especially since this
is expressed through a _form_ style (not an _application_
style).

What term should I use to describe a non-MDI window?
Then you first have to tell me what you consider to be a
non-MDI window.
Lets try: when
FormStyle == fsMDIForm ok that we could call a MDI window
FormStyle == fsMDIChild ok that we could call a MDI window
FormStyle == fsStayOnTop
No we could not call that a MDI window.
But.. if it was part of an MDI application ... ?
Hans.
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Phil Colbert wrote:
Quote
For example, if you have three groups of closely-related
windows, and five windows in each group, then
you could turn each group into its own fsMDIForm. It would
make conceptual as well as visual sense. It would also
keep users from mixing up unrelated windows, and thinking
that they were related.

But if the VCL doesn't support it,
then we might as well forget about it.
MDI is out. Better take a fsNormal form as mainform.
Place a TPageControl on it and use TTabSheets for every
mdichild you would otherwise have.
For each group take a fsNormal form with a TPageControl.
Now you can have as many groups as you want.
Hans.
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Hans Galema < XXXX@XXXXX.COM >wrote:
Quote
Phil Colbert wrote:

>In the program's main menu, the user chooses what kind of
>object he wishes to edit. This creates an SDI window,
>on the desktop,
I call them SDI windows because they are not MDI.
If there's another name for non-MDI windows,
I'll be happy to use it.
Quote
Heh ? That is not my idea of an SDI application. An SDI
application does NOT create extra windows. It has only one
mainwindow. If it is a textediter it can only handle one
text(file). If you want to edit two files then two instances
of the applications will be started. Of course it can have
a lot of dialogs and other helpwindows.
I call it an SDI app because it is not MDI.
If there's another name for non-MDI apps,
I'll be happy to use it.
This program is part of a design/modelling system.
There are about a hundred kinds of objects. Objects
are stored in a database. Users can pull any number of
objects out at the same time, for examination and editing.
Most objects are built in building-block fashion, out of
other objects, not by copying, but by reference. This
allows an object definition error to be corrected just
once, in one place, instead of hundreds of times, in
hundreds of places.
This approach allows a very complex subject to be broken
down into pieces that are individually easy to understand
and reuse.
But it can create a lot of windows, especially when users
follow the links from object (window) to object (window).
MDI came in as one possible means of coralling the clutter,
by collecting groups of related objects (windows)
into coherent chunks.
Multiple groups, of course, means multiple fsMDIForms.
Thanks to you, I think I understand VCL's MDI
well enough now to evaluate it in the context of
our needs. If there can be only one fsMDIForm in
the entire app, then it won't work for what I had
in mind. That's too bad, but this isn't the only
organizational approach I've been pursuing.
Thanks again.
-Phil
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

In article <42287303$ XXXX@XXXXX.COM >,
XXXX@XXXXX.COM says...
Quote

Hans Galema < XXXX@XXXXX.COM >wrote:
>>All of these windows are of style fsNormal. That makes
>>them all SDI windows, doesn't it?
>
>No. A window is never SDI.

Sorry. Applications can be either MDI or SDI. I thought
it would be the same for windows. Especially since this
is expressed through a _form_ style (not an _application_
style).

What term should I use to describe a non-MDI window?
A normal window IMHO.
Quote

-Phil

It is possible to make 2 MDI windows, the only problem is that any child
made is placed in the mainform.
VCL is using the Application variable to bind a child to the parent.
(Application->MainForm) (=read-only);
You can how ever create a MDI window and several 'normal' windows.
 

Re:moving an SDI application into mixed (MDI+SDI) mode -- how to?

Hans Galema < XXXX@XXXXX.COM >wrote:
Quote
MDI is out. Better take a fsNormal form as mainform.
Place a TPageControl on it and use TTabSheets for every
mdichild you would otherwise have.

For each group take a fsNormal form with a TPageControl.

Now you can have as many groups as you want.

Hans.
Ah, if I only had the luxury of such redesign. Perhaps
in a year or two...
Tab sheets would actually work for the object definition
windows. They're generic, and program-generated.
The generator doesn't care whether it lays out the
GUI components directly on a form, on a panel, or on
a tab sheet.
The problem is detail records. They come in so many
varieties and compression modes and display modes,
there seemed no way to handle them with tab sheets.
I used forms, and lots and lots of form inheritance
to help organize it all.
So, I am stuck with a big form-based application,
with many, many custom forms, and
form inheritance four to six levels deep in places.
It's very hard to turn one such form into a TTabSheet.
Making 30 of them into tab sheets would be a nightmare.
Even if I created custom TTabSheet descendants,
I couldn't edit them visually, the way you can with
Forms, and TPageControl wouldn't create them, anyway.
TFrame would do the job. But for other reasons,
the app is stuck for now in Builder 3, which
doesn't have TFrame.
Eventually, I'll be allowed time to redesign it all.
I'll probably use frames, tabbed pages, and
Builder 6 or Builder 2005.
But until then, I have to work with the existing
implementation, including certain inflexibilities.
You can see why I was so interested in MDI.
Taking an existing form and making it an
MDI child is easy, compared to the alternatives.
Any other options come to mind?
-Phil