acedCMD Synchronous Causes Problems with selection by window / crossing

[absStructural]

There are a ton of threads relating to sending a command via .NET, but I have been unable to find anything relating to this problem - so don't jump down my throat just yet 🙂

I followed the sample given here: http://adndevblog.typepad.com/autocad/2012/04/synchronously-send-and-wait-for-commands-in-autocad-us... 

which shows how to call a command from .NET and wait for it to finish before returning.  The problem I am facing is that if instead of INSERT, I use a command that prompts for a selection (COPY, STRETCH, etc) - I am unable to make selections by window or crossing (i.e. I can only pick one at a time). 

I believe this results from sending user pauses to the command line.  Any suggestions?

[DiningPhilosopher]

Yep - That's how it works these days (and is the same with LISP's (command) function too).

I don't see much need for pausing for most commands until they finished, with perhaps a few exceptions like INSERT, PLINE, SPLINE, PEDIT, etc.  

So, dependent on what underlying problem you're trying to use this technique to solve is, there may be other ways to do it, like the command-related events of the Editor class.

[absStructural]

I looked briefly at the events in Editor, and didn't see anything that would be overly useful.  Perhaps you can elaborate.

I am trying to write a few small utility functions that do this:

1. Allow the user to select an entity to align the UCS to (i.e. ECS)

2. Run some command (like move, stretch, copy, rotate)

3. Restore the UCS to what it was before this command was called

I can accomplish 1 and 3 just fine - but 3 requires waiting for 2 to complete.

[DiningPhilosopher · Accepted solution]

Sorry, I said events of the Editor class, but what I should have said were events of the Document class, namely the CommandXxxxx events.

The problem with nesting commands using acedCmd() goes beyond those you mentioned. They also include isses related to context-sensitive menus, ribbon tabs, and so forth. In your scenario, the user would expect that while the command whose completion your are waiting for is active and being used interactively, context menus for that command and ribbon contextual tabs for that command will be active and working properly.

Well, forget it.

So ironically, this problem is actually better solved using the Document's SendStringToExecute() method.

You can call it to start the command whose completion you want to wait for.

Before calling SendStringToExecute() to start that command, add a handler to Document's CommandWillStart event. In the handler of that event, remove the handler from CommandWillStart, and add handlers for the CommandEnded, CommandCanclled, and CommandFailed events. In the handlers for those events, you can get control after the command you started via the call to SendStringToExecute() has ended

[absStructural]

That's a fair solution.  Thank you for your input - it is much appreciated.