If your application is supposed to use both the original, non-right-sensitive version and your own improved version, then the name absolutely has to express what the derived class does. Otherwise everyone navigating the code base will go nuts understanding what the difference is and where it applies or not. Something like RightSensitiveTreeView is probably your best bet, even though it is already clumsy and will become much more clumsy if you ever need to express more than one extended behaviour.

But if you use the extended version exclusively, there is little harm in using a euphonious, even proud name like LouisTreeView – it will stay accurate even if you add more enhancements later, since those presumably will also be used everywhere. The only thing you should not do is reuse the original name exactly and disambiguate by putting it into a different package path. That is just asking for confusion.

(Disclaimer: proverbially, there are only two really hard things in computer science – cache invalidation and naming things. This is my opinion, but people will probably come forward with very different views.)

For a single class like your TreeView subclass that just adds a small amount of functionality, it’s probably not necessary to try too hard to make a good name. Personally I would make do with CustomTreeView or similar. Then the actual “Custom” bit can be described in some docs or comments above the class definition.

However suppose you have several of these classes, each extending TreeView in some small way. Then a generic name like the above wouldn’t cut it. You could attempt to name each customisation descriptively but then you things could go south – “RightSensitiveTreeView” for example is a bit lengthy for a class name.

If you want to add bits of functionality to a class, consider this approach: Create one subclass in your application (or personal/company library) and call it CustomTreeView or whatever. Make it work identically to TreeView by default. Add properties/methods that enable/disable the extended functionality – say, a selectOnRightClick property would do nicely for your extension. Then you can add as many customisations as you like to your one subclass, and all code that uses your subclass automatically has access to those customisations, with minimal change to code.

If it’s just generic functionality that will probably be wanted anytime you use such a control, such as changing items on right-click, I usually just add Ex to the end of my class to signify it’s an extended version of the class. For example, TreeViewEx or TabControlEx

The actual word being used doesn’t really matter, but I do try and keep it consistent throughout all my customized classes, and generic so I can add other functionality later if needed without having to rename the class (Ex, Extended, Custom, etc).

Of course, if the control does something specialized that is unlikely to be wanted in other cases when using that control, then I’ll add a more descriptive suffix to the control name instead.

I also add the word at the end of the control name (TreeViewCustom instead of CustomTreeView) so it pops up in auto-complete when you try and use the standard control.