Tony, I am so sorry. You are absolutely correct, and apparently I
needed to be humbled. I'm okay with that, but wish it hadn't involved
wasting your time in the process, or so much time period.
Somehow all this time, with all the variations I've tested, I missed
actually testing the very set of conditions I originally thought wasn't
working the same, namely SendCommand within an application context
command. I said previously regarding that non application context
sample code I posted...
{quote}
Add CommandFlags.Session because the command runs across multiple
documents and you have the essence of my original question.
{quote}
... which is wrong. Apparently I was assuming something I only thought
I had specifically tested. Without CommandFlags.Session (as posted),
the sample works differently between VBA and VB.Net, as asserted, but
with CommandFlags.Session they work exactly the same which completely
eliminates my problem. I do find it interesting that apparently
SendCommand and SendStringToExecute are not equal in this regard. It
looks as though SendStringToExecute is in fact asynchronous whether in
application or document context even though SendCommand differs
depending on the context.
I'm attaching some code I was paring down to prove my point, which
instead (thankfully) served to prove your point, that they do not behave
differently. It's an oversimplified version of working code just to
show one example of the kind of process which brought this up, but may
somehow be useful to you or someone else.
I am very glad that I was wrong, but sure wish I had discovered so far
sooner, for both our sakes. Thank you very much Tony.
--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO
Tony Tanzillo wrote:
> {quote}
>
> Whether or not it should have been done that way, it was and has worked
> quite nicely for us for several years.
>
> {quote}
>
> I'm not sure what exactly 'that way' means, but as I said, it depends on
> what commands are run, and whether AutoCAD polls for input during them.
>
> Aside from that, SendCommand() should not behave differently when called
> from VBA, verses from any in-process COM client (e.g., VB.NET) when the call
> is made from the same execution context. What I do know, is that VBA code
> can behave differently when run directly from the VBA IDE, verses when it's
> started via VBARUN, et. al.
>
>
>