Which pushbutton caused the ExternalCommand ?

[Anonymous]

Hi,

I have a large number of ExternalCommands I am using, so instead of creating a different Autodesk::Revit::UI::IExternalCommand for each button, I am trying to have only one class that implements the External Command interface and all buttons call it (by using the same class name whenever I add a pushbutton to the Ribbon)

- Then inside the Execute function I will decide which function to call, the problem is I don't know which button caused the Command, is there a way to know which RibbonItem was pressed ? or get it's name or any data ?

- Another problem with that, can I save some user data to the button, so when it is clicked I can get it, like an internal ID or something like that ?

[Revitalizer · Accepted solution]

Dear waleed,

you could subscribe to the UIElementActivated event using UIAutomation:

http://thebuildingcoder.typepad.com/blog/2011/02/pimp-my-autocad-or-revit-ribbon.html

But in fact I don't see the advantage in putting all commands into a super-command.

If you want to create many commands that are similar to each other, what about creating them at runtime ?

Just google for these keywords:

Microsoft.CSharp, System.CodeDom.Compiler, System.Reflection

or CSharpCodeProvider, ICodeCompiler, CompileAssemblyFromSource(),...

Best regards,

Revitalizer

[ollikat]

---

- Then inside the Execute function I will decide which function to call

---

Hi

Your approach is not very object oriented way of doing things. It means that there are more elegant (easy, convenient etc) ways of doing things than that.

If I would be you, I would consider one base class inheriting IExternalCommand and then other base classes inheriting that class. There are some obvious advantages...

- You can have code for common things for all the commands in one place.

- You can utilize virtuality and thus easily call the code you currently need to

You could check out the "template method" design pattern which is often used in this kind of situations.

http://en.wikipedia.org/wiki/Template_method_pattern

[Anonymous]

Hi Revitalizer,

Perfect, That was exactly what I am looking for, Thanks.

The advantage of using a super-command is I will have only one point of enty to my application thus making it easier to maintain.

[Anonymous]

Hi ollikat,

Thanks for your reply, The problem with using your suggestion is I will have to create a class for each type of command, which makes things more difficult if I wanted to change the way I am handling calls, but with a single point of entry I will only have to change it once.

[ollikat]

Hi

Well there's at least thousand ways of doing things and good that you find the solution you prefer.

Although I have to say that in my approach there can be a single entry point if only the base class implements the interface method (Execute). From there you could call some virtual method, which in turn is implemented in inheriting class. Yes, it's true that then you must do class for each command, but IMO it only brings advantages compared that you must have own function for every command.