I have a main form at present it has a tab control and 3 data grids (DevExpress xtragrid’s). Along with the normal buttons combo boxes… I would say 2/3 rds of the methods in the main form are related to customizing the grids or their relevant event handlers to handle data input. This is making the main forms code become larger and larger.
What is an ok sort of code length for a main form?
How should I move around the code if necesary? I am currently thinking about creating a user control for each grid and dumping it’s methods in there.
I build a fair number of apps at my shop and try to avoid, as a general rule, to clog up main forms with a bunch of control-specific code. Rather, I’ll encapsulate behaviors and state setup into some commonly reusable user controls and stick that stuff in the user controls’ files instead.
I don’t have a magic number I shoot for in the main form, instead I’ll use the ‘Why would I put this here?’ test. If I can’t come up with a good reason as to why I’m thinking of putting the code in the main form, I’ll avoid it. Otherwise, as you’ve mentioned, the main form starts growing and it becomes a real pain to manage everything.
I like to put my glue code (event handler stuff, etc.) separate from the main form itself.
At a minimum, I’ll utilize some regions to separate the code out into logically grouped chunks. Granted, many folks hate the #region/#endregion constructs, but I’ve got the keystrokes pretty much all memorized so it isn’t an issue for me. I like to use them simply because it organizes things nicely and collapses down well in VS.
In a nutshell, I don’t put anything in the main form unless I convince myself it belongs there. There are a bunch of good patterns out there that, when employed, help to avoid the big heaping pile that otherwise tends to develop. I looked back at one file I had early on in my career and the darn thing was 10K lines long… absolutely ridiculous!
Anyway, that is my two cents.
Have a good one!