Using StepInto

[James_Grey]

You shouldn't have to set the command to be enabled. If it is disabled, that is because conditions are not right to execute it. Is it disabled?

Does the step into button work? Did you make another custom button that invokes your step-into code? Does it not work at the same time that the connected button does work? If so, are you using the same view manager for the connection as you do in your step-into code?

[Dia]

No it is enabled.

The Step-Into button works. I did not make another button that invokes my step-into code though. I will try that to test my code.

I am using the same view manager as the in the step-into code.

[Dia]

Posted my last reply too soon.

I just tried fitting a button with my "StepInto" code it works just fine. Now, why isn't it working when I use that code within a loop or another function call. It is necessary that I be able to do that since this is all going to be part of an automation system I'm working on. I want to be able to StepInto each test step to analyze it.

[James_Grey]

How and when is the non-working code being invoked? What event triggers it? This code is in the main thread of your operator interface application, right?

[James_Grey]

Note that you can't just sit in a loop indefinitely in response to an event in your main gui thread. Your main thread needs to run its message processing loop. For example, if your main thread does not process messages, all execution threads will hang the next time they send a trace message because they will be waiting for the gui thread to process it.

[Dia]

The non-working code is being invoked from a function call before the message processing loop in the CWinApp implementation of InitInstance. The code from the function being called is below as is:

mApplicationMgr->OpenSequenceFile(fileName);
mApplicationMgr->BreakOnFirstStep=true;
mSequenceFileViewMgr->Run();
this->mExecutionViewMgr->GetCommand(CommandKind_StepInto, 0)->Execute(true);

Note that in the future I would like to use the StepInto code within a loop. What changes would you think are required?

[James_Grey]

I suspect that code doesn't work because you are calling Step Into before the start-execution or display-execution events could possibly be processed. Thus the executionviewmgr thinks there is still nothing to step into. It would be better to call step into in response to a break event. You could add state variables to your app so you can tell which break event is one you want to step into for.

As for looping, you shouldn't do it. Your main gui thread should always be left free to process events. To drive a periodic action that is not triggered by another event, I'd recommend using a timer event in conjunction with whatever application state variables you might need.

[Dia]

I don't get what you mean by "calling Step Into before the start-execution or display-execution events". I can't find such events any where on the UI ref poster.

Maybe I should point out that the sequence does actually open and the application responds to my Run command and stops on first step like desired. Also, when I get rid of that function call and attach that entire block of code from the function to a button, it does not work as well.

Maybe there's something missing from where I tell the function to Run and where I want it to StepInto?

[James_Grey]

I thought you had said that it did work when you attached it to a button?

The events I'm referring to are ApplicationMgr.StartExecution, ApplicationMgr.DisplayExecution, and ExecutionViewMgr.Break.

However, the fundamental thing to understand is that SequenceFileViewMgr.Run is an asynchronous method. It starts a new thread and immediately returns.

The new thread will send the events I mentioned (and more) and it will eventually break. However, since you call step-into immediately after calling Run:

a) You haven't returned to let the GUI process events so that even if the execution has started, it will still be waiting for the gui thread to dispatch the DisplayExecution event. Until that event is handled, the execution won't be assigned to an ExecutionViewMgr, thus any call to an ExecutionViewMgr could not affect it.

b)Even if this were not the case, you still have a race condition in that you might call step into before your execution actually breaks at the first step. A call to step into while the execution is not suspended is ignored (ie the command is not enabled).

Thus, you should use the events the managers generate to determine the correct time to call step into, which for you is probably when you get a break event.

[Dia]

Ok, Events actually work fine for now for what I want to try to accomplish. I will post later if any issues arise.

I appreciate the help and excuse my lack of knowledge in both MFC and TS.

Thank you.