05-17-2010 09:21 AM
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?
Solved! Go to Solution.
05-17-2010 10:00 AM
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.
05-28-2010 07:10 AM
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.
05-28-2010 09:44 AM
05-28-2010 09:59 AM
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.
05-28-2010 10:16 AM
05-28-2010 12:09 PM - edited 05-28-2010 12:13 PM
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