Bonnie,

I knew it wouldn't be easy.

>Gregory,
>
>I don't think there's a problem having a lot of files, but in this case it doesn't seem necessary ... at least not to me, YMMV. I have one file that I call Control.cs. In it I have about 30 classes, which sub-class most of the commonly-used Controls, such as TextBox, ListBox, CheckBox, ComboBox (actually, I have several kinds of ComboBoxes), etc. These are all non-visually-designable classes and are all relatively small classes. If I were to break those out into individual files, I don't see what the point would be. The project that these controls belong to also contain visually-designed classes and there are a lot of those too (like Form sub-classes and various UserControl classes). I like to keep the non-visually-designed classes all in that one Controls.cs file so that I don't clutter up the project with a bazillion files.
>
>Again, it's just my preference and I don't think it really matters in the grand scheme of things. =0)
>
>~~Bonnie
>
>
>
>
>>Bonnie,
>>
>>Would the number of files be a problem - provided one keeps a folder/subfolder struct to group them ?
>>I can even imagine splitting one class into several files - keeping related methods/properties together
>>
>>Is putting a lot of classes into one file any better ?
>>
>>I wonder whether there's one answer to this question
>>
>>
>>
>>>Pete,
>>>
>>>I know that you probably did this because it's been recommended (by me and others) to put all these non-visually-designable classes into one file. But, I'm wondering why you now want to separate them each into their own separate files? That will be quite a large number of files. It's really quite alright to leave them in one file.
>>>
>>>~~Bonnie
>>>
>>>
>>>
>>>>Hi All, I currently have all of the common .NET control classes defined in one ( getting bigger by the day ) file and am thinking of separating them into individual .cs's - does anyone know of a tool on the market that does this ? has anyone here written such a thing ?