Question

Locked

How to make a dynamic C# form?

By navdeepz ·
HI, i hope the question is not too misleading because I've been trying to think of the best possible way to describe it. Okay here is the situation(although i do not want the exact answer or the code but a little help and a few hints would be really helpful), well I've just started with Project development using C# and well the thing is that i have a MAIN FORM say FORM1.
When the application starts what i want is the
FORM 1 to stay with a dialogue that comes up asking what options the user wants. Let the options be OPT1 and OPT2
so if the user clicks on OPT1 the dialogue box closes and the form one has a button panel on coming on the right hand side and the complete working is done on the left hand of the FORM1.
Similar is the case with OPT2 .

Things that i have understood:-
i can keep OPT1 and OPT2 and can call it through making component. but i want to know how would the MAIN FORM- FORM1 be designed ...

Thanks.

This conversation is currently closed to new comments.

8 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Answers

Collapse -

Well a dialog box is a form

by Tony Hopkinson In reply to How to make a dynamic C# ...

but there are three basic ways to approach this

The quick and simple one would be to take the option1 or 2 bit out of main form.
Ie make the dialog box the main form, or simply present it in the main routine (program.cs by default).
At the moment that says create and show Form1
Create and Showmodal a dialog. pick up the Option from it and then pass it in to your current main form, have it bring up the relevant bits and pieces.

Quick and dirty option is
If you don't want to do that, ie you want your current form1 up as a backdrop for the dialog to give it some context.
Then you you just raise the dalog and deal with the result in FormCreate (careful though you can get some funnies that way), or formactivate (a flag property to say you've already asked the question and don't need to ask it again (or even better you do want to ask it again would be a good idea).

If I had the time to do it proper then I'd have a FormController class.
The problem with your current approach is you'll end up with MainForm and optionForm's 1 and 2 having to know way too much about each other in order to communicate common events (clicking a button on Main form does something in an optionForm and vice versa). You end up closely coupled, (come up wth an OptionForm 3 three and see what happens....)

If you move all the common stuff to a controller class with it's own state property (which option was chosen) and always communicate through it....

I'd also do it through a set of interfaces, that way if you want to twiddle wth the implementation of any of the forms, it will be clear exactly what needs to be implemented by a form. IMain, IOptionDialog, IOption etc. Makes unit testing a heck of a lot easier as well.

HtHs

Collapse -

Reponse To Answer

by navdeepz In reply to Well a dialog box is a fo ...

I do wanna try the dirty one ... BUT after i get a little more hang of what I am making... and i also have been thinking of what u suggested ... initially when the application is made to run a dialogue box appears directly asking for the user to choose the option and then redirecting it to the respective forms... i just didnt know how to do it .. now that i have a little track i shall do more research on the how to present the dialogue box in the main routine ... And if i dont get it .. im gonna disturb you again :) thanks for the help much appreciated.

Collapse -

Reponse To Answer

by navdeepz In reply to Well a dialog box is a fo ...

Oh and a little more information... well i tried making the dialogue box as the main form but well that dialogue box always remains unless i use this.close() (which inturn terminates the application) or this.hide() (which does hides the form1 but it keeps running in the background).

Well the application that i am making is actually two things combined in one. I am combining a SALARY MANAGEMENT with another module that would keep a record of the incoming PRODUCTION ORDERS and the outgoing orders.

P.S:- Making it for my Dads production house.

i guess this would make things more clearer :)

Collapse -

Reponse To Answer

by Tony Hopkinson In reply to Well a dialog box is a fo ...

I must have mispoke a bit there when I said make the dialog box the main form.

I didnt mean MessageDlg.Show()
I meant do a form with your selections on it
Then create that and show it modally, the result you then pass in to your mainform (constructor is one option). Do that in program.cs.

Or you can create main form as you are now, and then raise the dialog in say FormActivate, pass the result to a setup method that sorts out the other form etc.

I wouldn't use either of the quick methods for what you are doing, they are for when you exactly waht you are going to do, you need to do it quick, and you accept the technical debt you are going to get for version 2.

If you go down the route you are, you are going to be in a right mess when you want to add more modules.
If there's eniough meat on the main form functionality, I'd look at MEF (Micosoft Extension Frameworls and got for a plug-in architecture as an option as well.

Collapse -

Reponse To Answer

by Tony Hopkinson In reply to Well a dialog box is a fo ...

Oh and based on putting the code in Program.cs, or FormActivate, how are you going to switch from one module to another, close the app, re run it and choose the other option....
ControllerClass and interfaces or plug-in got to be the way to go.

Collapse -

Reponse To Answer

by navdeepz In reply to Well a dialog box is a fo ...

Hi,
well I've tried a lot of options . I did look into MEF and have been trying to understand some stuff. Well its kind of tough. I did find out an alternative to the problem. Well what i thought of was --

1. I create a component for the option1 and option2.
2. call it in a main form using MDI form.
3. the choice of option can further call upon various other forms.

P.S:- altough i would later on re-develop this application using better tools once i get to know how to use them properly (i.e MEF) but for now how do you think would this application do. More over do you think using the MDI form is a wise idea with respect to business application development point of view.

Collapse -

Reponse To Answer

by Tony Hopkinson In reply to Well a dialog box is a fo ...

Never liked MDI myself. If you keep it simple, ie all teh clid windows have exactly the same interface / or the same base class, it works and you get window management and such for free. If hoevere you want to stray from that and have multiple windows, showing different types of things, you can get in right mess quick. All depends on how similar they are. No big thing, if it's working it's good, if the design breaks down, then you kick MDi into touch and have to write the bits that want, e.g. the list of windows in the app and selecting ones of them, refreshing the windowlist when one is added or deleted etc.
The key point is the more you bodge MDI to keepit, when (and I do mean when) the wheels come off and you have to drop MDI, most of the bodges will have you pulling you hair out. So if it starts breaking down, my advice is to bite the bullet and do your own, not try to keep limping sadly along, to avoid a couple of days effort.

Collapse -

Reponse To Answer

by navdeepz In reply to Well a dialog box is a fo ...

well yes thats true .. using to many child forms is kind of a mess .. but i do not really like the multiple windows opening up for button i press i like to keep it all in one window. but then i dont see any other options available to me to make just one windowed application .

Back to Software Forum
8 total posts (Page 1 of 1)  

Related Discussions

Related Forums