The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Navigation in winforms

I am trying to come up with a best way to navigate between forms in windows application(using C# language).

I was using the usual way like writing the following code in the button click event.

FormHome frmHome = new FormHome(username, this);
frmHome.Show();
this.Hide();  // 0r this.Close();

Which is the best possible way to navigate between Forms.
Kuldeep P Send private email
Monday, November 10, 2008
 
 
Don't use different forms. Use different user controls on a single form. Hide one and show the next. It's much less jarring to your users.
uggh
Monday, November 10, 2008
 
 
This is the best way to do :
use delegates---

http://www.codeproject.com/KB/cs/PassDataWinForms.aspx

passing values in constructor parameters is childish now that we have delegates...
Achintya Jha Send private email
Monday, November 10, 2008
 
 
1) The OP wasn't asking about how to pass data. The OP was really more interested in "navigation" (activating, showing, hiding forms).

2) Using delegates/events on the main form is far from the best way to pass data between forms. It is only workable if you have a small number of parameters and forms. It is also a lot more work than simply adding a property or two to a form and setting/reading it directly as needed. Finally, it creates a coupling between the child form and the main form such that the child form can't be easily reused by multiple forms because each would have to create the same eventing structure. It usually makes a lot more sense for the child form to be completely self contained and to expose an API that consumers can use.
uggh
Monday, November 10, 2008
 
 
++ uggh

And, if the child form requires certain information to be valid, it makes far more sense to pass that information in the constructor rather than to create the form then call a delegate.
Ewan McNab Send private email
Monday, November 10, 2008
 
 
If the requirement is to only have one form from the app on screen at a time, then I would definitely go for uggh's suggestion over the OP's.

But sometimes, just opening multiple forms as top level windows can be the right choice. For example, if you have a form for looking up records and open a separate form for each record selected from the lookup form, you allow users that may have to juggle multiple tasks requiring access to different records to keep those records available until they're finished with them. A single window design would require such a user to completely back out of the current screen to lookup something else, unless you also allow separate instances of the top level app window.

The downside is that you impose a minimum of two window management on the user, but I think that further spawning of windows/forms can be minimized by using tab controls or user controls as uggh suggests.
Chris Altmann
Monday, November 10, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz