Form with many different layouts based on options

  • Thread starter Thread starter Lucas Tam
  • Start date Start date
L

Lucas Tam

Hi all,

What is the best way to do this:

-I have a form, that has a couple of options (paths through the program),
A, B, and C.
-Each option has it own set of displays

In essence I have:

StartDisplay <-select which "path" to take
A1, A2, A3
B1, B2, B3, B4
C1, C2, C3, etc.
EndDisplay <-basically the same for all options

Is it a good idea to build each option as a User Control then swap the
controls out of a form dynamically? I'm doing this right now and it works
OK, but I'm wondering if there is a more elegant solution.

Or, should I just create 1 form for each option?

Thanks.
 
Hi Lucas,

You'd have them on the same form if there is a reason to. What reasons do
you have?

Some questions to consider:

What is common in the user interface?
What is common in the program logic?
Is the form just a shell for the user controls?
How would it help the user to have it all on one form?
Would the user care or even know if you did it with three forms?
How would it help you as a developer to put it all on one form?

Lastly, why do you think it may be better to do it another way? What is it
that strikes you as 'unclean' about your current approach?

Regards,
Fergus
 
Lucas,
There are not much "best" solutions with VB.net

You have so many possibilities to get what you want, that you can do things
on the way you like it.

In this case:
Some make different forms, because that is easy to keep up with changes.
Some make tab pages (beside the wish of the user) the same reason as above
but less flexible as above
Some hide controls which has the same problems as your method
Your method which is a little bit making it in the dark in my eyes, but when
it's done who cares.
And probably there are a lot of other possibilities.

My opinion is, take what you fits the best.
Cor
 
Hi Fergus,
Good Morning still active?
We did give almost the same answer in the same time I think.
Cor
 
Hi Lucas,

You'd have them on the same form if there is a reason to. What
reasons do
you have?

Some questions to consider:

What is common in the user interface?
Click to expand...

I'm really building an wizard that can handle different file formats.
Hence the majority of the page is standard (i.e. Next, Back, Cancel
Buttons, a Datagrid, etc), but the actual options per page are different.
What is common in the program logic?
Click to expand...

Nothing at all, so I encapsulated the login the user controls.
Is the form just a shell for the user controls?
Click to expand...

Yup, exactly. This is OK right? I wanted to avoid having multiple forms
to keep updates as simple as possible.
Lastly, why do you think it may be better to do it another way?
Click to expand...

I'm just wondering if there is another way. Currently I have a standard
form, which I swap the user control in and out dynamically. The control
contains the functionality pertient to the page.
What is it
that strikes you as 'unclean' about your current approach?
Click to expand...

I'm just worried that when I have more paths to add, I'll need a lot of
logic to handle all the possiblities. I guess that's a given... hence I
wanted to know how other people have built a similar application
(Basically a Wizard that processes different file types in different
ways).
 
Hi Lucas,

From your answers it seems that you're on to a good thing. I've not done
any wizards myself, but container-with-flow-control plus separate juicy bits
would be my fancy.

The single wizards that I've used have either been single page by single
page with Prev/Next, or tabbed pages where you can click on the tabs as well
as use Prev/Next. I like these personally because they allow me to jump back
two pages to change something. They also show me how long the process is and
where I am.

Your situation is different. You can do either of the above (or anything
you like) with your wizards, but you want <multiples> of these. I think
keeping them separate as you have done is a fine method. I reckon that there
may be common logic to the separate wizard, even within the UserControls, so
I'd look to take as much of that into a base class.

From your first post's example, A1, A2, A3, B1, B2, etc. it seems that the
paths are discrete. I know that was highly simplified to get the point across,
but now that we know where we're at, what's the issue with the 'more paths'
bit ?

Regards,
Fergus
 
From your first post's example, A1, A2, A3, B1, B2, etc. it seems
that the
paths are discrete. I know that was highly simplified to get the point
across, but now that we know where we're at, what's the issue with the
'more paths' bit ?
Click to expand...

Thanks for your responses. From what you wrote, it seems that what I'm
doing is "OK" so far by ecapsulating each page's element in a user
control.

What I meant by more paths is say in the future the wizard has to handle
different options (Oracle DB, MySQL, etc etc), then I'll need to add
customized paths for each. Hence, I'm worried that my flow control logic
would become much more complex.

Anyhow, here is basically how I control flow (in case you're curious):


Select Case OptionType

Case Option #1
DisplayOption1Page(Page#)
Case Option #2
DisplayOption2Page(Page#)
Case Option #3
DisplayOption3Page(Page#)
End Case

The procedure DisplayOption1Page(Page#) would then have logic to
load/remove the user controls based on which page the user is on.

I just thought there might be something more elegant... somewhat similar
to ASP Master Pages for ASP.NET.

Thanks alot for your comments... I really appreaciate the input. It help
put down some of the concerns I had.
 
Back
Top