If I'm not mistaken, if a dialog temporarily hides itself to allow the user to supply graphical input (e.g, picking points), SendCommand() can not run synchronously.
Can acedCmd, apart from an indication that something went wrong?
Take this command string:
string args = System.String.Format("_Flatshot {0},{1},{2} 1.0 1.0 0.0\n", p.X, p.Y, p.Z);
Picking an existing block won't work. But feeding it to SendCommand and just clicking "Create" kind of does, in a way, perhaps.
It actually has a lot to do with how Flatshot is implemented. When using
acedCmd() from an ObjectARX command, there is a risk of running out of
command-nesting levels (which I believe is 4 levels). So, if your command
executes an AutoCAD command that itself executes one or more other
AutoCAD commands internally, the number of nested command invocations
can be more than AutoCAD allows, and the whole thing goes up on smoke.
The way around that is to use
[LispFunction("C:COMMANDNAME")] rather
than
[CommandMethod("COMMANDNAME")], to define the command.
Many internal commands check to see if they're being scripted from LISP
(or acedCmd() more precisely) and do things differently to accommodate
that, so I suspect that because it is very much
by-design that FLATSHOT
not be scriptable, it most-likely doesn't do much in support of scripting, and
could even be doing things to sabotage attempts to script it.
Another cause of many problems with scripting AutoCAD commands that
have GUIs, is the Action Recorder (The layer dialogs are an example). To
be recordable a GUI command does everything by sending commands to
the command line using an internal equivalent of SendStringToExecute().
That can really mess up attempts to script commands too.
Other possible causes of problems are running acedCmd() inside of a
transaction, and not ensuring that a command that is started by a call
to acedCmd() has ended before the command that calls it ends, which
usually crashes AutoCAD because nested transactions are not ended
in the reverse order in which they were started.