Simple (hopefully) form question

[Guest]

I need to create an application that uses primarily a single form rather than
an SDI that creates a new form for everythting. However, I don't want an MDI
style application since the users I'm dealing with would be overwhelmed with
it.

The approach I tried in the past was to use MDI, but made all the child
windows occupy the entire parent area without a frame so it looked like a
single window. I also allowed only a single instance of each form to keep it
simple. This gave me the merged menus and the appearance I wanted, but the
performance of that solution wasn't great, so I don't want to go down that
path again.

I guess I want it to work sort of like frames in HTML, replacing the work
surface with objects that would normally be in a new form in a classic SDI
app.

I assume the solution is simple and common, but I'm a solo developer new to
..NET, so I don't have anyone to bounce this off of.

Thanks in advance for any suggestions.

 

[Daniel]

Ever thought of using one big window and putting everything else in panels
within that window?

Should do what your after i think

 

[Guest]

I considered it, but I was hoping there were more elegant solutions out
there. I like using separate forms because it allows me to isolate code and
I don't end up with huge case statements all over for decisioning when the
users selects a menu option and such.

I may be that panels are the best solution though. I'm primarily a DBA and
..NET development is still new to me.

 

[Daniel]

I thought you were trying to to make separate forms everywhere?

Personally i would do it on separate forms, i only sugested the panel method
as i thought this is what you wanted to avoid.

Bit confused what the problem is.

 

[Guest]

I'm trying to provide the users with what appears to be a single form with a
menu and work areas that change based on context. The end users are confused
by having multiple windows open and the application really doesn't require
it. The only thing I want to use additional forms for is to display dialogs;
Other than that all interaction should be contained within the one form.

In the past - using 1.1 - I had used the single MDI form with all its
children contained within it to make it appear it was a single form whose
display surface changed appropriately, whereas it was actually creating
borderless MDI children within the bound of the parent. This gave me easy
access to merging of menus, form events, and such. While I'm sure it wasn't
the correct way to do it the end users were happy and it made my life easier.
Performance wasn't great and every child form was first drawn with its title
bar, then it was erased, causing the form to appear to "bounce" within the
parent. Though I haven't tried it in 2.0 yet I was told by Microsoft that it
was a bug in 1.1 and was not fixed in 2.0.

I would like to do this new project the "right" way, if there can ever be
such a thing.

 

[cSharpLess]

"Byron" <[email protected]> kirjoitti
viestissä:[email protected]...

I guess I want it to work sort of like frames in HTML, replacing the work
surface with objects that would normally be in a new form in a classic SDI
app.

Maybe try to create and use each view as user control that you use then on
form?

<snip>