Which is better: TerminateExecution() or GetCommand(CommandKinds.CommandKind_Terminate)?

[tlaford]

When issuing commands to an execution from a home made application, is it better to use the ExecutionViewMgr methods RunSelectedSteps(), BreakExecution(), ResumeExecution(), and TerminateExecution() or to use the GetCommand() method and pass in the CommandKinds (CommandKind_ExecutionEntryPoints_Set, CommandKind_Break, CommandKind_Resume, CommandKind_Terminate)?

Is one way more efficient than the other?

[James_Grey · Accepted solution]

There isn't a noticable difference in efficiency. The Command objects just add extra functionality such as the ability to determine if the action is currently applicable (Command.Enabled), the ability to connect the action to buttons and menu options, PreCommandExecute and PostCommandExecute events, undo/redo for editing actions, etc.

You can use either for things like Terminate. Personally, I always use Commands.

[tlaford]

Does GetCommand() perform the action in the same thread?

The reason I ask is that I used GetCommand(CommandKind_Break) to pause the execution when my Trace() callback detects a failed step.  But sometimes it stops immediately (as I want it to) and sometimes it processes an extra step before stopping.

It's as if using GetCommand() doesn't process the pause request immediately, but instead puts it on a queue which may or may not get handed before the next step is executed.

[James_Grey]

GetCommand creates a Command wrapper around an action. Whether that action occurs in the current thread or not depends on the action. In this case, it is wrapping a call to Execution.Break. I believe that Execution.Break does indeed put a request to suspend in a queue that is processed by another thread. I'm not sure how to ensure the break takes effect before the next step. As an ugly work around, you might try inserting a delay after the call to break.

[tlaford]

When I use this.axExecutionViewMgr.GetCommand(CommandKinds.CommandKind_Break).Execute(true); I can consistently cause it to pause one step later than I expect by having a lot of stuff running (i.e., a busy CPU).

But when I updated my code to use this.axExecutionViewMgr.BreakExecution(); instead, It always stops at the step I want it to.

[James_Grey]

They both ultimately call the same code. This is a race condition and the command does fire Pre and Post Command events which might affect the timing. However, I admit I don't fully understand since I would have expected that doing more in the gui thread after issuing the break would have make it less likely to occur, but that is apparently not the case.

[dug9000]

Calling break on an execution is asynchronous in multiple ways:

1) The call doesn't actually initiate the break directly, it passes the work off to another thread and returns immediately. Thus the break might not have even been requested yet when it returns.

2) If the execution is running, calling break from the UI thread, even if 1) didn't exist,  would still give you unpredictable behavior because the execution is still running and could be at the step after the one you expect because the break is done in a different thread.

If the execution is suspended at a trace event or some other synchrous event and you are seeing the problem then it is likely because of 1), if the execution is not suspended then it could be because of 1) or 2). If you know the execution is suspended until your return (i.e. you are handling a trace event or something) then you can workaround 1) by adding a short delay (i.e. Thread.Sleep(500)) after you initiate the break command in order for it to get processed.

Hope this helps,

-Doug

Message Edited by dug9000 on 05-28-2010 12:13 PM