I've found a difference in running VBA macros from the Intellicad command prompt versus from inside the VBA editor environment.

Running my VBA from the editor, it always works as predicted. There is a big difference running a macro from the command prompt, using the -VBARUN command.

For example, running 'Trav1' (a function which traverses a line over a bearing from point to point and allows the user to select starting coordinates) using the -VBARUN command, when the user selects the option to select starting coordinates, the user input prompt does not appear....instead the prompt just reads 'Macro name: Trav1"

To not crash the instance of Intellicad that I'm running, I have to close the active drawing. After that, the next form pops up (as if user input had been completed). After closing that form (and thus the running VBA), the user input prompt appears (sometimes as garbage characters).

The same behavior is exhibited with other user input prompts if running an individual macro from the intelliCAD command prompt.

I'm looking for an alternative method to running the macros that will not override user input.

It would seem that I'm learning the CAD environment faster than the programming environment

This issue is resolved by displaying the forms with user input as modeless. So, in the above example, the Trav1 form was being displayed modally (meaning that the user can not interface with outside applications while running). Setting the ShowModal property to False gives the desired results.

This property defaults to true when a userform is inserted in the VBAIDE. In AutoCAD it doesn't seem to make a difference. Of course, there was a lot of work done inbetween the start of the conversion project and now, that could've altered the behavior of the code in intelliCAD.

Given the nature of the program that's being designed on our end, it makes sense to make as many forms modeless as possible, and only the most important forms modal. Microsoft suggests coding the other way, as users might access the forms unpredictably. I suggest that this is where you really sit down and design your code before just writing it...as now I'm having to go back through it and make fairly simple, repetitive changes that should've just been done the first time.

It all comes back to what I said at the top of the post, because it's obvious that if I'd known more about the VBA environment, and how to write code for it, I would've already considered this when starting the project.