Sorry, … I edited my previous post, as I can see how it looked like I was disagreeing with you.
All true. (I did not mean to make it look like this was untrue. I edited my previous post.)
… because it has created a native C++ menu item. The native Shortcuts panel (of the Preferences dialog,) enumerates menus and the items on them, on the native (C++) side of the code.
Aerilius’ Toolbar Editor is a Ruby extension, which is limited to using only whatever has been exposed to Ruby, by the SketchUp development team. (And not everything about the UI has been exposed to the APIs.)
So it is not really that they are like apples and oranges, … but rather they are both apples, but in different orchards. And one orchard is off limits.
As I tried to explain above, menu items can be, but do not have to be, exposed as Ruby UI::Command objects. There are older quick and dirty ways to create a menu item, that does not create a lasting interface. After the creation code ends (ie, goes out of scope,) there is no longer any way (via the SketchUp Ruby APIs) for the original programmer, any other programmer or plugin, to get a reference to these menu items.
If the original programmer just enclosed the plugin command code in the block for the add_item() method, then there is no way to execute that code other than clicking the menu item.
But a better form of coding would be to enclose the command’s code within a named method, and the menu item block or the UI::Command block simply calls that named method. (A method is known as a function or procedure in other languages.)
Of course it would be. But first, you need to get all the extension programmers to adhere to some standard, when it comes to writing their UI interfaces. Sounds simple, but in practice it is not. Such standards have been proposed but everyone just has their own style, and it is like pulling teeth to get everyone to agree on one single standard.
When I write an extension with multiple commands, I like to expose them in a collection called “Commands” (usually a hash with the command name as the key.)
But the authors of some commercial extensions do not do this, and may not want any other extension calling their commands. There is history where plugins have been collected and packaged, without the owners’ permissions, and distributed with a “collection toolbar”.
Now, the Ruby language has built-in methods for introspection and reflection. It may be possible to use these method calls, to interrogate the Ruby objectspace, in order to deduce what the namespace object name is that is wrapping Chris’ extension, and then interrogate it to list it’s method names. Possibly you could then figure out what the name of the “Repeat Copy” command method is, and then use a fully qualified method call in for your custom toolbar button.
Ex:
ScottsModule::NiftyPlugin.do_some_command()
But this requires that the extension, (to be interrogated,) be loaded.
I do not have it, and I am not going to go pay ten dollars just to answer your question.
So, this is why it is best for Chris to give you the answer on what the method call snippet is.
Because usually, actual plugins / extensions do not use introspection methods. It is something done by programmers at the console. (Window > Ruby Console)
You need to refer to the Ruby Core documentation for the Kernel module, Object, Module, and Class classes. (Kernel is included into Object, which is the mother of everything. So everything else inherits their methods. Class is the subclass of Module so all classes inherit methods from class Module.)