Multiple forms?
Hi,
I am making the jump from asp.net to windows so I have very little experience with Windows forms.
Requirements:
The user leaves the office with a tablet or notebook and travels to a site.
The user selects 1 of 4 reports to enter various data.
Each report is vastly different than the other and will display at least a screen’s worth of controls.
Here is how I think it should be done:
I add a top menu labeled “Reports” with 4 sub-menus displaying each report name.
The click event for each sub-menu switches to a different report Windows form.
Questions:
1). Does this sound reasonable?
2). How do I switch between forms while maintaining the top menu?
Thanks
Jody
It is so amazing to read this question because I am so much more used to the problems an experienced desktop developer has when trying to translate their skills and perspective to web development. This is almost like reading it inside out.
Since you are just starting, I would suggest the very classic MDI approach.
This is like when you open up Word and then you can open up individual documents inside of there. So the MDI form acts as a container for your other forms. You can control it so that only one form can be opened at a time, or you can allow your users to open multiple forms (reports data entry) at a time. To control all of this, you can use a toolbar control.
That is a classic desktop way to do it.
So, like Word, the "shell" and it's menu just stay there while the child forms come and go.
Here's an example by Ken Getz and Paul Sherrif. This says it assumes some VB background, but I think it will get you started.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/getstarwinform.asp
One thing to keep in mind is that you are NOT dealing with postbacks. This is very very different. You have a much more tangible cause and effect of actions on the screen.
I will be curious to follow your progress through this, because I am very interested in your perspective of coming from the web to the desktop.
Hi Julia,
A retraction:
When I said, “I have very little experience with Windows forms”, what I really meant to say was that “I have very little experience with .Net Windows forms”. I was a Microsoft VC++ Windows developer before I started doing Web work. It has been a few years since I did any serious windows development but I don’t seem to recall ever developing an MDI application. What I do remember is that in one application I was switching in and out CFormViews in a SDI application. I was hoping to something like that again here.
After reading my experience from above do you still think MDI is the way to go for me?
Even if your opinion changes from what I said above I going to run with your suggestion and develop it using MDI and C#. This project is supposed to be a learning experience and since I havn't completed an MDI application this is a good time to start.
I will let you know how it turns out.
Thanks,
Jody
No problem. It was fun to write that post anyway!
There are lots of paths you can take. I must admit, I have not done any MDI's with my winforms apps yet. All of my vb6 apps are mdi though. So far all of the winforms apps have only required an sdi interface.
Next one is actually going to use on-the-fly embedded controls.
MDI seems like a simply natural route for what you are doing.
It is an interesting idea, though, isn't it? A web programmer trying to write an application without postbacks!
<g>
julie
Hi Julia,
You were absolutely correct for the MDI call. It is really easy to setup and code.
Since you were so helpful, and I am short on time, I have a few questions for you if you don’t mind.
1). I need to include a login form. It is always customary to do a popup dialog (then where do I attach it to, the main form)?
2). I am looking ahead and I am calculating that the main entry form will contain about 3 screen pages long of controls. There are 3 main divisions: Text/Ink input controls, Combo box controls, and Help/Text data. Is there a good way to*space
space*up the main page?
Thanks again,
Jody
Jody-
1) I'd probably do the login before I even activate the MDI form. That way you don't have all of that mdi stuff already hanging around if the login fails. This way, the login form is not attached to anything. Not sure if I said that clearly. Do the login. When that succeeds, then start up the MDI form.
2) My personal preference for that is tabbed pages.
Desktop Apps give you lots of new toys, don't they? <g>
julie
Hi Julia,
Yeah, the tabbed page concept seems like a good idea.
So here is the new plan:
I will use a 3 tabbed page control for each of the 4 entry reports.
Here is the wrinkle; I want the first tab of each report to look the same.
Before going with the tab concept I had created a base windows form which I had intended to use for the top of each report. That seems to work well.
Is it possible to inherit just one tab page for a tab control or do I create a base class that has the same number (3) of tab pages that will be used by the end user class?
Thanks again,
Jody
hmmm..
there are a few paths that I would consider, though not sure which is the best...
1) create a control that has whatever you wanted on the top of each form. Create the forms separately, add the tab control, define the # of tabs (think future - you may someday need a report that has more than 3) and then drop that control on them
2) create a base form that has the tab control on it already. Expose the # of tabs so taht you still have the flexibility. The base form then already has the tab and your common stuff of the first page. Then just inherit that form to create your different report forms.
3) As you were contemplating, create a control that inherits the tab form and put your "stuff" on it. Then use THAT control on your report form. If you do this, be sure to expose any properties or methods of the tab that you may need to use down the road.
Just some ideas. There are probably other ways, also.
julie
