C# Windows Forms - panels?

[mlm]

I don't even know how to explain it because I don't know the technical terms, but how do you go from one "screen" to the next in a Windows Form? Would this be a panel?

Does anybody know where I can find an easy example of this so I can figure out how to implement it?

 

[esun]

I don't have a lot of Windows Form experience, but one obvious way would be to set everything on screen 1 to invisible and set everything on screen 2 to visible.

 

[PhatoseAlpha]

Sounds like you're looking for multidocument functions. Lookup MDI (multi document interface) on google.

 

[Noobsa44]

A panel is inside a form. For example, if you have a list of items on the right, and when you click one the left side of the form updates. Another example would be a installer with a text field, a picture box and a next button, where the panel updates every time you press next, but it isn't a new form.

Alternatively, you might be describing a dialog box or another form. A dialog box is a simple prompt of some sort that pops up asking a question, like "Do you want to save changes?". Another form is something like winamp, where you have the main player and a separate window for the playlist.

Do any of those descriptions fit what you are trying to do? If not, can you describe it using another well known application?

 

[mlm]

Originally posted by: Noobsa44
Another example would be a installer with a text field, a picture box and a next button, where the panel updates every time you press next, but it isn't a new form.

I think this is what I'm looking for. An installer is probably the best thing I can think of. Would that involve putting the appropriate controls on each panel, and toggling the visible setting for each panel as you go along?

 

[Noobsa44]

Yes, the best way to do that is to have multiple panels with each appearing or disappear. Also, in some cases you may just want one of the controls to appear/disappear, for example you might make the cancel button disappear when you have finished an installation rather than having a brand new panel. As best I can tell (I'm no GUI expect), choosing between using panels or just hiding the individual controls is rather more an art than a science.

 

[mlm]

The thing that really gets me is how is the designer window possibly going to be manageable with all the overlapping controls you can add to it?

 

[Tencntraze]

Why not use tabs?

 

[xtknight]

You probably want to use the TabControl. http://www.functionx.com/vcsharp/Lesson07.htm

If you mean completely change the layout of the whole form with the click of a button, then enclose each mini-screen in a container and toggle the visibility of each container to switch between the two. If I had to guess though, that would be poor UI design unless you were doing a wizard. Even then, the tab control may be most suitable.

 

[xtknight]

Originally posted by: mlm
The thing that really gets me is how is the designer window possibly going to be manageable with all the overlapping controls you can add to it?

Some tab controls actually do all the work for you, so you can just click a tab in design time and design it from there. With others, your best bet is to just put them off to the side and resize your form to hide them. It really isn't too ideal once you get four or more tabs. I'm not sure how the TabControl works, but I'd guess it's at least as easy as one of the tab controls in VB6 where it did all the management for you during design time.

You might want to check out this "wizard" tutorial also, source code included: http://geekswithblogs.net/jann.../2005/03/14/55193.aspx

 

[pcnerd37]

From your description, I would recommend looking into MDI or the TabControl

 

[mlm]

The problem with tabs is I wouldn't want the "tab" portion to be visible, and I need to restrict the access order.

I've got it working in a manageable way so far with panels after fiddling with the underlying code. I'll have to look up the MDI thing though, I've never heard of it.

 

[Noobsa44]

I think you could override the tab functionality (even if they did remain visible) or at least disable them and just provide a next button. So say you have 3 tabs labeled step 1, step 2, step 3. You could have it so that users couldn't click on any of the tabs by disabling all the tabs except for the one you currently are on. Then you just provide next/back buttons and simple disable the current tab, enable the next tab and move forward a tab.

 

[Markbnj]

Originally posted by: mlm
The problem with tabs is I wouldn't want the "tab" portion to be visible, and I need to restrict the access order.

I've got it working in a manageable way so far with panels after fiddling with the underlying code. I'll have to look up the MDI thing though, I've never heard of it.

Yeah, this is a workflow, which is different from the event-driven nature of most of what a desktop app does. Whether you call it a wizard or not, that's essentially the paradigm you're operating in. MDI is not what you're after.

Most applications that do this only need a couple of steps. For example, maybe a main dialog to make changes then a confirmation dialog, or something like that. Shallow workflows are manageable using any of the techniques described here, such as turning containers on and off, or using separate dialogs. If the workflow is longer than a couple of steps I would stop and think it through carefully. Long workflows have an annoying habit of changing in the middle.

.Net 3.0 has support in the WPF for paged workflows. I think you have to cobble it together from panels in 2.0.

 

[dandragonrage]

Originally posted by: mlm
The thing that really gets me is how is the designer window possibly going to be manageable with all the overlapping controls you can add to it?

You can position them to be workable in the designer and have code that positions them correctly at load... Otherwise you keep right clicking and hitting send to back 'til you find the one you want.

 

[sao123]

Originally posted by: mlm

Originally posted by: Noobsa44
Another example would be a installer with a text field, a picture box and a next button, where the panel updates every time you press next, but it isn't a new form.

I think this is what I'm looking for. An installer is probably the best thing I can think of. Would that involve putting the appropriate controls on each panel, and toggling the visible setting for each panel as you go along?

why cant you just use a button on form 1 to (close form 1, open form 2)...
that was my understanding of how this is done.

 

[mlm]

Originally posted by: sao123

Originally posted by: mlm

Originally posted by: Noobsa44
Another example would be a installer with a text field, a picture box and a next button, where the panel updates every time you press next, but it isn't a new form.

I think this is what I'm looking for. An installer is probably the best thing I can think of. Would that involve putting the appropriate controls on each panel, and toggling the visible setting for each panel as you go along?

why cant you just use a button on form 1 to (close form 1, open form 2)...
that was my understanding of how this is done.

From a usability standpoint, it's a pain to have windows constantly opening and closing.

 

[mlm]

Originally posted by: Markbnj

Originally posted by: mlm
The problem with tabs is I wouldn't want the "tab" portion to be visible, and I need to restrict the access order.

I've got it working in a manageable way so far with panels after fiddling with the underlying code. I'll have to look up the MDI thing though, I've never heard of it.

Yeah, this is a workflow, which is different from the event-driven nature of most of what a desktop app does. Whether you call it a wizard or not, that's essentially the paradigm you're operating in. MDI is not what you're after.

Most applications that do this only need a couple of steps. For example, maybe a main dialog to make changes then a confirmation dialog, or something like that. Shallow workflows are manageable using any of the techniques described here, such as turning containers on and off, or using separate dialogs. If the workflow is longer than a couple of steps I would stop and think it through carefully. Long workflows have an annoying habit of changing in the middle.

.Net 3.0 has support in the WPF for paged workflows. I think you have to cobble it together from panels in 2.0.

At this time I don't think the workflow would be too convoluted. Basically right now it's:
Login/Select Action screen (select action) -> Action screen -> Select Action screen -> etc. You never go more than one screen deep except for one action that uses a second window for data entry.

All of the actions are almost exactly the same except for a few fields, so it works to use the same panel for all of them while hiding the irrelevant parts. If I ever have to implement something that's completely different (which I'm pretty sure I will), I would put it on another panel.

 

[sao123]

Originally posted by: mlm

Originally posted by: Markbnj

Originally posted by: mlm
The problem with tabs is I wouldn't want the "tab" portion to be visible, and I need to restrict the access order.

I've got it working in a manageable way so far with panels after fiddling with the underlying code. I'll have to look up the MDI thing though, I've never heard of it.

Yeah, this is a workflow, which is different from the event-driven nature of most of what a desktop app does. Whether you call it a wizard or not, that's essentially the paradigm you're operating in. MDI is not what you're after.

Most applications that do this only need a couple of steps. For example, maybe a main dialog to make changes then a confirmation dialog, or something like that. Shallow workflows are manageable using any of the techniques described here, such as turning containers on and off, or using separate dialogs. If the workflow is longer than a couple of steps I would stop and think it through carefully. Long workflows have an annoying habit of changing in the middle.

.Net 3.0 has support in the WPF for paged workflows. I think you have to cobble it together from panels in 2.0.

At this time I don't think the workflow would be too convoluted. Basically right now it's:
Login/Select Action screen (select action) -> Action screen -> Select Action screen -> etc. You never go more than one screen deep except for one action that uses a second window for data entry.

All of the actions are almost exactly the same except for a few fields, so it works to use the same panel for all of them while hiding the irrelevant parts. If I ever have to implement something that's completely different (which I'm pretty sure I will), I would put it on another panel.

the proper way to build it would be through an inheritance tree...
you would have a base form (everything they have in common) then some derived forms...
dynamic form changing is not really that popular in .net 2.0 as it was in MFC... primarily because it is so easy and quick to do everything.