Happy Bhai Dooj to you!
This greeting comes from my colleague Sandeep Kumar in Bangalore, who explains:
Bhai Dooj is a festival of prayers from sister to brother, brother's protection for her sister. May we all celebrate this Bhai Dooj with even more love and protection for our sisters and brothers. Best wishes on this Bhai Dooj.
Thus fortified, let us turn to a Revit API issue, based on this excerpt from a useful little chat I had yesterday that might be of general use:
Question: My external application displays a large number of all kinds of ribbon items. Now I thought I might implement one single handler class for all of the external commands these items can trigger, instead of creating a separate one for each. I would like to create only one CommandHandler class derived from IExternalCommand, and decide which function is required in its Execute method. The problem I have is that the ExternalCommandData instance passed in does not provide any information about the source of the event, so there is no way of knowing which RibbonItem was clicked. Is there a way to get that information, e.g. retrieve the name of the button clicked or something?
Answer: A good idea. It makes perfect sense. Unfortunately, no, this is not possible.
At least, the Revit API does not give you this access. You might possibly have more luck using .NET UI Automation. It probably provides UI Automation events that can let you find out what button was clicked.
Using the standard Revit API functionality, you really do have to implement a separate command for each button. You can easily funnel them all into the same handler yourself afterwards, if you like. That would achieve almost what you want. Implement a separate command for each button, determine which button was clicked, and then funnel all calls into the same command handler method. The handler method can check the source of the event and branch out again appropriately.
Addendum: In his comment below, Rudolf Honke points to the very interesting discussion thread on which pushbutton caused the ExternalCommand where Revitalizer and ollikat expound on various alternative solutions, e.g. subscribing to the UIElementActivated event, creating commands at runtime and implementing one single base class inheriting IExternalCommand and other command classes derived from it.