Is it possible to provide arguments to pushbuttondata command classes?

[Anonymous]

I am not sure I have properly described the question in the subject. Instead of using just the string classname for the last argument of pushbuttondata I would like to pass the classname with an argument for that command classname to use. This would mean setting up the command class to take an argument. Is that possible? Thank you.   

[jeremytammik]

Nope, sorry.

You need to implement a separate class for each external command.

They can obviously be derived from a common base class.

Each separate command implementation can simply specify the argument value you like and then call a common method on the base class.

That will achieve almost exactly what you are asking for.

• Base class MyExternalCommandBase implements Execute taking additional argument.
• Derived class MyExternalCommandA derived from MyExternalCommandBase call execute specifying additional argument A.
• Derived class MyExternalCommandB derived from MyExternalCommandBase call execute specifying additional argument B.
• etc.

Cheers,

Jeremy

[Anonymous]

Oh well, there goes that idea. I was hoping to simplify something that has multiple but essentially identical commands to a single item taking an argument. Having the ability would also open the possibility for a ribbon to build itself based upon information in an external text file.

Thank you

[jeremytammik]

Absolutely not. The approach I described supports that idea, and I am sure that many developers use that very approach. In fact, I do so myself in The Building Coder and other samples. Every time I have two or more commands doing very similar things with very similar code, I implement one common execution method for them and reduce the actual external command implementation class to a one-liner calling that.

A prime example of driving ribbon construction by a text file is the Revit SDK RvtSamples external application.

It creates a ribbon menu with over hundred entries for all the Revit SDK samples, populated from a text file, and furthermore supports include files, which I use to pull in one hundred more external commands from The Building Coder samples, implemented back in 2008:

http://thebuildingcoder.typepad.com/blog/2008/11/loading-the-building-coder-samples.html

Cheers,

Jeremy

[Anonymous]

Ok, but if I correctly understand, the "Loading The Building Coder Samples" describes how the interface is built from a text file that contains interface data for uniquely named command classes that already exist. The individual command classes that I want to consolidate are already one-liners with an argument to another class. Those arguments originate at the command classes assigned to ribbon controls. Therefore a different command class is required to already exist for each ribbon control even though the only difference between them is arguments that, in my mind, should originate at the ribbon elements. Originating at the ribbon element makes sense to me because add-ins seem to be able to create their interfaces as they load. Not being able to pass data to a universal task command class from the ribbon element seems like the only thing standing in the way of some desirable flexibility. 

[Anonymous]

I agree with aksaks.

I'm currently trying to use a combobox that has different text strings.  I want the user to be able to click the desired combobox item, and have that string pass down to the DLL class and Execute subroutine.  As far as I can tell, I'm not able to take the strings from my buttons and comboboxes and pass them to the revit plugin.  

I'm considering making a temporary text file that writes from the when the user clicks (then have the child DLL read the text), but it looks like I'm unable to code event subroutines to write the file once the button has been clicked as well.  There ain't much we can do for workarounds on this.