Printable View
I have a piece of software that has over 30 screens ( and growing ), that are all required and relevant, etc.
What is the best way of building and managing multiple screens with C# and Windows Forms .net 3.5?
Currently, I'm building each screen as a user control, and then adding that control to my main form of the application. But this is something that is going to be huge, and I'm looking for any feedback on 'best practices' of multiple screen management.
I would suggest using a MDI form.
Take a look here
http://www.c-sharpcorner.com/UploadF...sinCSharp.aspx
http://www.codeproject.com/KB/cs/mdiformstutorial.aspx
30 screens isn't that much some of my database programs contains more then 100 different views.Quote:
Originally Posted by mattk_wd
Basically in C# we have a 'Form' So
a) why using Usercontrols instead of Forms
b) You may have to differ between screens that contains only one form and screens where multiple forms are on the same screen.
For example look at our IDE You have the Form where you put all the code, but you also have the Form wher each part of the project is listed in a tree and you have tools which you can pop up on the screen when needed. Additional there are Dialogs which can be opened and closed while all others should stay in place, not to talk about all the debug windos. There are lots of 'Dockable Forms ' Solutions on the market which allows you to arrange them on the screen just in a similar way we have in the IDE.
Modern programs are orientated on the users needs and are trying to grant a bit of indivdual 'UserStyle' ( the way how to arrange the forms, which forms I'm wanting to have on screen and all that )
Basically I fully agree with danny. You should look at MDI Forms and the mainForm should be such one. But I want to expand that.
You need to differentiate. Which forms should be MDI children, which are only sort of tools additionally needed from some user or not ( so they are maybe wanted as dockable ) Which are needed to be opened in lots of instances and which are single instantiated.
Lets give an example by an accountancy program which also has lots of screen
There are screens for example where you can enter data to the account of a specific customer so this is maybe a child Form which is Single Instantiated and then you may want to have a look into different accounts while doing that so this should be Forms which are multi-instantiable so you should be able to have more then one on the screen in the same time, if needed. This forms could be MDI children or maybe you want them as dockable thats your decision.
During work some people would ike to have a list of all the accountnumbers and accountnames ( especially when they are new i that job and didn't know them by hard ) So it is needed to have a list of all account available, that should be Dockable I think, but is not necessarily Single Instantiated. Maybe someone would have three lists of accounts like one for all debit account one for the credit accounts and one for standard accounts like cash account, tax account... Then he would prefer not to have one endless list but instead of that three different lists, which are all based on the same basic Dockable Form, only containing different data ineach instance.
So you see: Only telling us that there are 30 screens is to less to give you any advice how to roll up the whole bunch.
Basically start there
a) DESIGN
what is needed and wanted
How is the work don
which screens are needed for which purpose
which elements are needed on each screen
how do the screens interact with each other
which totally different forms are needed, which are basicaly the same but only containing different data.
Which needs to be multi instantiated, which should be Singletone
After all this is completely cleared and only when this is totally clear
decide which layers you will have in your program ( so where your screens are controlled and where your data are coming from - going to. MVP Pattern or MCP pattern will be useful in most cases.
So I think thats enough for a first hint :D
BTW Maybe you want to read my article series about Dockable forms: See the links in the bottom of the page