Create overloaded members in ClassDesigner
Overloaded members are treated specially in ClassDesigner: they’re grouped together when listed in the shape, and there’re few limitations when you want to create overloaded members. Today we will talk about the various ways and limitations to create overloaded members in ClassDesigner.
How do I create an overloaded method/property?
1. Using Class Details window.
Just as you can use Class Details window to create normal members, you can use it to create overloaded ones as well. Just type in the first member you want to create, then type in the second one to create an overload, and add a distinct list of parameters so that they’re valid overloads.
2. Rename an existing member to create an overload:
As mentioned in previous articles, you can perform rename-refactoring from both inside the shape and in Class Details window (and you can do it from Property Browser as well):
Once you commit the change, Class Designer will do a sanity check to see if the two methods’ signatures will collide after the renaming. If so, you will get the following warning to cancel your change:
Once renamed, the two members will be grouped together:
Why make a specific article on creating overloaded members?
Creation of overloaded methods is special because it introduces an temporary state of uncompilable code until you give each overloaded one a distinct signature. Except for the second way above to rename an existing member to create an overload when that member happens to have a distinct signature, all the methods above will create two members with the same signature. We have thought about this a lot and decided that it’s better to let the user fix up the signatures than to insert some placeholder parameters to create unique signatures. For this reason, it is recommended that you fix up the signature asap and think of it as part of the creating overloaded member process. If the invalid overloads are left unchanged while you keep working on these members in Class Designer, you may experience errors (none of them are fatal/unrecoverable, but may still be annoying). This is especially common when working with VB, in which the design-time environment does more compilation checks than C# and J#.
Visual Studio Class Designer Team