load and run VBA macro from the command line
You need to run it as a lisp command using the vla-runmacro command. See the lisp example at the bottom of the page I linked.
Ed
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
How to post your code.
You can't send vba or other code to the command line, only commands and lisp.
Ed
Did you find this post helpful? Feel free to Like this post.
Did your question get successfully answered? Then click on the ACCEPT SOLUTION button.
How to post your code.
To run VBA code, with built-in commands, you need to load the *.dvb file first and then run it. It looks like you want to start to run a VBA macro from a ribbon menu item created via .NET API, using Document.SendStringToExecute(). As far as I can see, the string content you passed to the SendStringToExecute() is missing a trailing space (" ") or a ";" (I usually use " "). That is, if you want to call a command "MyCommand", then the code should be:
dwg.SendStringToExecute("MyCommand ", ... ...).
Because you want to run a VBA macro, it would be better to use this lisp function:
(vl-vbarun "myVbaProject.dvb!moduleName.MacroName")
With this lisp function:
1. you can either prefix the file path of the DVB file, or you can leave the path out, as long as the DVB file can be find in one of the support paths of current user profile.
2. you do not have to care if the DVB file is loaded or not. this function would load the DVB file first, if it has not been loaded.
So, the code for your .NET ribbon ICommand would look like:
doc.SendStringToExecute("(vl-vbarun \"TheVBA.dvb!TheModule.TheMacro\") ", true, false, true);
It might be better to define a Lisp command that runs the VBA macro:
(defun c:MacroCmd ()
(vl-vbarun "[paht/file].dbv!module.macro")
)
and then include this lisp command in, say, acad.lsp, so that it is always loaded.
Then in your .NET code, where SendStringToExecute() is called, you simply pass the command name "MacroCmd " (notice the trailing space). The advantage of using this approach is, you can update/change the VBA file/code freely without having to recompile your .NET code, as long as the list defined command "MacroCmd" is not changed.
I guess you are in a transition stage of moving to .NET API development, but have many existing functionalities in VBA code. Using a Lisp-defined command in between your .NET app and VBA app, so they are loosely decoupled, would make the transition more flexible.
HTH.
