I'm working on a databound CheckListBox and things are going well, but the name I chose for it is bugging me.

Because the control CheckListBox already exists, I didn't want to name it that, and instead chose P_CheckListBox (the P represents the first letter of the company name) and is stored in a DLL of its own, but I'm just not sure, the P_ prefix will allow for nice grouping in the intellisense but I just have a feeling it's not a good thing to do.

How do you name your custom controls that derive from, or logically would have a name of, an existing control?

Oh, also, when creating a custom control, is there any performance change if deriving from UserControl and placing one control that is Dock:Fill on the surface, or just deriving directly from the control itself?

I tend to name it based on what I'm adding to the control. Using your control as an example, it would be DataboundCheckListBox. I use namespaces for keeping stuff organized by company.

And no, there really isn't a performance change, it's more of a "what am I trying to accomplish here" thing. If you are only going to have the one control, I'd derive from the actual control itself.


Yeah I use namespaces to organize as well. I actually have changed the name to just CheckListBox for now, but I like your idea, I just hate objects with long names, and crazy long namespaces and to me DataboundCheckListBox is on the edge of being too long for me to stand. Probably something I need to get over.

I think as far as deriving from UserControl or the actual control itself, I have it set-up to derive from UserControl now, and I think I'm actually going to keep it like that just to hide the inherited CheckListBox properties that, if are filled in at design time could cause the control to screw up. I'd rather have my custom properties take care of those. I'm aware you can hide the properties by overriding them and/or marking them as not browsable, but this covers it :)

Thanks for the feedback! I really do appreciate it!