Simple (hopefully) form question

[Byron]

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

"Byron" <By***@discussi ons.microsoft.c om> wrote in message
news:6F******** *************** ***********@mic rosoft.com...

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.

[Byron]

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" wrote:

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

Should do what your after i think

"Byron" <By***@discussi ons.microsoft.c om> wrote in message
news:6F******** *************** ***********@mic rosoft.com...

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]

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.

"Byron" <By***@discussi ons.microsoft.c om> wrote in message
news:E1******** *************** ***********@mic rosoft.com...

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" wrote:

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

Should do what your after i think

"Byron" <By***@discussi ons.microsoft.c om> wrote in message
news:6F******** *************** ***********@mic rosoft.com...

>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.

[Byron]

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.
"Daniel" wrote:

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.

"Byron" <By***@discussi ons.microsoft.c om> wrote in message
news:E1******** *************** ***********@mic rosoft.com...

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" wrote:

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

Should do what your after i think

"Byron" <By***@discussi ons.microsoft.c om> wrote in message
news:6F******** *************** ***********@mic rosoft.com...
>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.

[cSharpLess]

"Byron" <By***@discussi ons.microsoft.c om> kirjoitti
viestissä:6F*** *************** *************** *@microsoft.com ...

<snip>

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>