Synchronous SendCommand within Application Context Command?

[Anonymous]

Is it possible in .Net/ARX (without using a modeless form)? It seems
odd that this, which works in VBA, would not be possible in .Net/ARX.

From what I've read and seen:
acedCmd runs synchronously, but not at all in application context.
SendStringToExecute (or COM SendCommand) run in application context, but
asynchronously.

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO

[Anonymous]

What's different about SendCommand() when called from VBA, verses VB.NET ?

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009

http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");


"James Allen" wrote in message
news:6213329@discussion.autodesk.com...
Is it possible in .Net/ARX (without using a modeless form)? It seems
odd that this, which works in VBA, would not be possible in .Net/ARX.

From what I've read and seen:
acedCmd runs synchronously, but not at all in application context.
SendStringToExecute (or COM SendCommand) run in application context, but
asynchronously.

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO

[Anonymous]

Sequencing. Please see the following code. It is synchronous in VBA,
provided it is not called directly from a lisp routine (indirectly via
vla-SendCommand works though: something you helped me with several years
ago). But in VB.Net it doesn't run until after completion of the outer
command.

I was pondering along the lines of that vla-SendCommand lisp solution,
and the similar standard SendStringToExecute to trigger a defined
document command from a modeless form. I discovered that I could
acedInvoke synchronously from application context and tried tricking it
by dynamically invoking a non application context LispFunction which in
turn would acedCmd or SendCommand what I needed, but ultimately all the
behavior remained the same. In fact I found that a command call within
a pure lisp defun fails if called via acedInvoke from an application
context. I figure it is internally using the same thing as acedCmd.

It's not a show stopper for me yet but sure has slowed down progress
significantly.

{code}
Imports AcAp = Autodesk.AutoCAD. _
ApplicationServices.Application
Imports Autodesk.AutoCAD.Interop
Imports Autodesk.AutoCAD.Runtime

Public Module sct
_
Public Sub sct()
Dim d As AcadDocument
'Set d = ThisDrawing
d = AcAp.AcadApplication.ActiveDocument
d.Utility.Prompt("Before.")
d.SendCommand("During.")
d.Utility.Prompt("After.")
'VBA: "Before.During.After."
'VB.Net: "Before.After.During."
End Sub
End Module
{code}

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO



Tony Tanzillo wrote:
> What's different about SendCommand() when called from VBA, verses VB.NET ?
>
>

[Anonymous]

That code isn't running in the application context, it's
running in the document context.

In the document context, my advice is to avoid both
SendCommand() and SendStringToExecute() entirely,
and use acedCmd().

See http://www.caddzone.com/CommandLine.vb


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009

http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");


"James Allen" wrote in message
news:6213677@discussion.autodesk.com...
Sequencing. Please see the following code. It is synchronous in VBA,
provided it is not called directly from a lisp routine (indirectly via
vla-SendCommand works though: something you helped me with several years
ago). But in VB.Net it doesn't run until after completion of the outer
command.

I was pondering along the lines of that vla-SendCommand lisp solution,
and the similar standard SendStringToExecute to trigger a defined
document command from a modeless form. I discovered that I could
acedInvoke synchronously from application context and tried tricking it
by dynamically invoking a non application context LispFunction which in
turn would acedCmd or SendCommand what I needed, but ultimately all the
behavior remained the same. In fact I found that a command call within
a pure lisp defun fails if called via acedInvoke from an application
context. I figure it is internally using the same thing as acedCmd.

It's not a show stopper for me yet but sure has slowed down progress
significantly.

{code}
Imports AcAp = Autodesk.AutoCAD. _
ApplicationServices.Application
Imports Autodesk.AutoCAD.Interop
Imports Autodesk.AutoCAD.Runtime

Public Module sct
_
Public Sub sct()
Dim d As AcadDocument
'Set d = ThisDrawing
d = AcAp.AcadApplication.ActiveDocument
d.Utility.Prompt("Before.")
d.SendCommand("During.")
d.Utility.Prompt("After.")
'VBA: "Before.During.After."
'VB.Net: "Before.After.During."
End Sub
End Module
{code}

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO



Tony Tanzillo wrote:
> What's different about SendCommand() when called from VBA, verses VB.NET ?
>
>

[Anonymous]

Right, that code was only in answer to the specific question of how
SendCommand differs between VBA and VB.Net. That specific difference is
the same in either context. Add CommandFlags.Session because the
command runs across multiple documents and you have the essence of my
original question.

Yes, I completely agree about acedCmd in the document context since it
removes the limitation of having to pass all arguments as strings and it
does work synchronously. I had actually bookmarked your code and tested
the approach in the process of trying to find an answer to this before
posting.

So my original question remains, is it possible to write a single .Net
command which does
"Before.During.After." in multiple documents, where "During." is any
flavor of command line call?

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO



Tony Tanzillo wrote:
> That code isn't running in the application context, it's
> running in the document context.
>
> In the document context, my advice is to avoid both
> SendCommand() and SendStringToExecute() entirely,
> and use acedCmd().
>
> See http://www.caddzone.com/CommandLine.vb
>
>
>

[Anonymous]

I'm not sure what you mean by 'in multiple documents'

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009

http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");


"James Allen" wrote in message
news:6213785@discussion.autodesk.com...
Right, that code was only in answer to the specific question of how
SendCommand differs between VBA and VB.Net. That specific difference is
the same in either context. Add CommandFlags.Session because the
command runs across multiple documents and you have the essence of my
original question.

Yes, I completely agree about acedCmd in the document context since it
removes the limitation of having to pass all arguments as strings and it
does work synchronously. I had actually bookmarked your code and tested
the approach in the process of trying to find an answer to this before
posting.

So my original question remains, is it possible to write a single .Net
command which does
"Before.During.After." in multiple documents, where "During." is any
flavor of command line call?

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO



Tony Tanzillo wrote:
> That code isn't running in the application context, it's
> running in the document context.
>
> In the document context, my advice is to avoid both
> SendCommand() and SendStringToExecute() entirely,
> and use acedCmd().
>
> See http://www.caddzone.com/CommandLine.vb
>
>
>

[Anonymous]

I mean sequentially open, process (incl. SendCommand), save, and close
multiple drawings without user interaction. For example, run a standard
cleanup sequence on a received drawing and each of its xrefs in turn,
all within a single CommandMethod issued in the top drawing.

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO



Tony Tanzillo wrote:
> I'm not sure what you mean by 'in multiple documents'
>
>

[Anonymous]

{quote}

So my original question remains, is it possible to write a single .Net
command which does
"Before.During.After." in multiple documents, where "During." is any
flavor of command line call?

{quote}

Well, that's not how it should be done to start with.

You shouldn't rely on multiple calls to SendCommand or its managed
counterpart working synchronously or in the order they're issued. It really
depends on what the commands you invoke do and if AutoCAD has to poll for
input during command execution.

The safest and most reliable way to drive the command line from the
application context is to define another command that executes in the
document context, and from the handler of that command, you can use the
command line (via acedCmd() or the class I referred you to) to execute
AutoCAD commands synchronously. From the same handler, you can do other
things that must wait until the AutoCAD commands have completed. Then, you
can invoke your custom document context command from the application context
via SendStringToExecute().

See the attached example.

--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009

http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");


"James Allen" wrote in message
news:6213785@discussion.autodesk.com...
Right, that code was only in answer to the specific question of how
SendCommand differs between VBA and VB.Net. That specific difference is
the same in either context. Add CommandFlags.Session because the
command runs across multiple documents and you have the essence of my
original question.

Yes, I completely agree about acedCmd in the document context since it
removes the limitation of having to pass all arguments as strings and it
does work synchronously. I had actually bookmarked your code and tested
the approach in the process of trying to find an answer to this before
posting.

So my original question remains, is it possible to write a single .Net
command which does
"Before.During.After." in multiple documents, where "During." is any
flavor of command line call?

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO



Tony Tanzillo wrote:
> That code isn't running in the application context, it's
> running in the document context.
>
> In the document context, my advice is to avoid both
> SendCommand() and SendStringToExecute() entirely,
> and use acedCmd().
>
> See http://www.caddzone.com/CommandLine.vb
>
>
>

[Anonymous]

Okay, thank you Tony. I was afraid of that.

Whether or not it should have been done that way, it was and has worked
quite nicely for us for several years.

I hoped I would be able to eliminate all the SendCommands but some
aren't going away. So now I need to refactor the project to the
App.SendStringToExecute("Doc.acedCmd") pattern, as you advised.

My current vision of how I'll handle the chaining/sequencing is a little
fuzzy, so I'll probably post again when I think I've got it and hope
you'll be willing to comment some more. Thank you for your patience.

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO



Tony Tanzillo wrote:
> {quote}
>
> So my original question remains, is it possible to write a single .Net
> command which does
> "Before.During.After." in multiple documents, where "During." is any
> flavor of command line call?
>
> {quote}
>
> Well, that's not how it should be done to start with.
>
> You shouldn't rely on multiple calls to SendCommand or its managed
> counterpart working synchronously or in the order they're issued. It really
> depends on what the commands you invoke do and if AutoCAD has to poll for
> input during command execution.
>
> The safest and most reliable way to drive the command line from the
> application context is to define another command that executes in the
> document context, and from the handler of that command, you can use the
> command line (via acedCmd() or the class I referred you to) to execute
> AutoCAD commands synchronously. From the same handler, you can do other
> things that must wait until the AutoCAD commands have completed. Then, you
> can invoke your custom document context command from the application context
> via SendStringToExecute().
>
> See the attached example.
>
>

[Anonymous]

{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.


--
http://www.caddzone.com

AcadXTabs: MDI Document Tabs for AutoCAD 2009
Supporting AutoCAD 2000 through 2009

http://www.acadxtabs.com

Introducing AcadXTabs 2010:
http://www.caddzone.com/acadxtabs/AcadXTabs2010.htm

Email: string.Format("{0}@{1}.com", "tonyt", "caddzone");


"James Allen" wrote in message
news:6214592@discussion.autodesk.com...
Okay, thank you Tony. I was afraid of that.

Whether or not it should have been done that way, it was and has worked
quite nicely for us for several years.

I hoped I would be able to eliminate all the SendCommands but some
aren't going away. So now I need to refactor the project to the
App.SendStringToExecute("Doc.acedCmd") pattern, as you advised.

My current vision of how I'll handle the chaining/sequencing is a little
fuzzy, so I'll probably post again when I think I've got it and hope
you'll be willing to comment some more. Thank you for your patience.

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO



Tony Tanzillo wrote:
> {quote}
>
> So my original question remains, is it possible to write a single .Net
> command which does
> "Before.During.After." in multiple documents, where "During." is any
> flavor of command line call?
>
> {quote}
>
> Well, that's not how it should be done to start with.
>
> You shouldn't rely on multiple calls to SendCommand or its managed
> counterpart working synchronously or in the order they're issued. It
> really
> depends on what the commands you invoke do and if AutoCAD has to poll for
> input during command execution.
>
> The safest and most reliable way to drive the command line from the
> application context is to define another command that executes in the
> document context, and from the handler of that command, you can use the
> command line (via acedCmd() or the class I referred you to) to execute
> AutoCAD commands synchronously. From the same handler, you can do other
> things that must wait until the AutoCAD commands have completed. Then, you
> can invoke your custom document context command from the application
> context
> via SendStringToExecute().
>
> See the attached example.
>
>

[Anonymous]

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.
>
>
>

[Anonymous]

For anyone looking for the conclusion at the end... Yes, it works, just
like in VBA.

I think my main fault was an assumption that SendStringToExecute and
SendCommand are equal, which appears to not be the case. They both run
asynchronously in the document context, but only SendCommand switches to
run synchronously in the application context.

--
James Allen
Malicoat-Winslow Engineers, P.C.
Columbia, MO



James Allen wrote:
> Is it possible in .Net/ARX (without using a modeless form)? It seems
> odd that this, which works in VBA, would not be possible in .Net/ARX.
>
> From what I've read and seen:
> acedCmd runs synchronously, but not at all in application context.
> SendStringToExecute (or COM SendCommand) run in application context, but
> asynchronously.
>
> --
> James Allen
> Malicoat-Winslow Engineers, P.C.
> Columbia, MO
>