VisualWorkflowTrackingWithStepService

In the last post, we went through the SDK sample where we saw how to use the Designer and the Debugger APIs to understand the workflow execution logic outside of VS in a visual manner. This is certainly one step above the textual tracking records received and making a sense out of it.

We will now go one step further. Customers generally ask, Is it possible to have a Re-hosted Debugging as such?

Well, not a full blown re-hosted debugger. But some capabilities of it – Certainly. One of the most important being the ability to set Breakpoints on the activities and the F5 behavior.

The way we go about that is again through the Debugger APIs. Last time, to get the debug kind of adornments, we did the following:

 this.WorkflowDesigner.DebugManagerView.CurrentLocation = srcLoc;

where srcLoc mapped to the Xaml activity line no. corresponding to the activity which is currently executing.

Taking these APIs one step further, we can set/remove breakpoints, as follows:

 if (e.Key == Key.F9)
{
     ModelItem mi = this.WorkflowDesigner.Context.Items.GetValue<Selection>().PrimarySelection;
     Activity a = mi.GetCurrentValue() as Activity;

     if (a != null)
     {
          SourceLocation srcLoc = designerSourceLocationMapping[a];
          if (!breakpointList.Contains(srcLoc))
          {
              this.WorkflowDesigner.Context.Services.GetService<IDesignerDebugView>().UpdateBreakpoint
                                          (
                                             srcLoc, BreakpointTypes.Bounded | BreakpointTypes.Enabled
                                          );
               breakpointList.Add(srcLoc);
          }
          else
          {
              this.WorkflowDesigner.Context.Services.GetService<IDesignerDebugView>().UpdateBreakpoint
                                          (
                                            srcLoc, BreakpointTypes.None
                                          );
               breakpointList.Remove(srcLoc);
           }
     }
 }

‘e’ corresponds to the KeyEventArgs that captures the key pressed down on the OnKeyDown event.

The UpdateBreakpoint API ensures which kind of breakpoint you can see on the designer surface. If a breakpoint doesn't exist already on that activity we set one, otherwise we toggle the breakpoint and remove it for the specific activity.

Similarly for the F5 behavior; we essentially create a flag which is set when a specific breakpoint is hit and unset, signaling the synchronous tracking to continue workflow execution, on the next F5.

Thus, in the ShowDebug method(when we show the Debug adornment on the activity that is executing), we add the new code:

 //Check if this is where any BP is set
bool isBreakpointHit = false;
foreach (SourceLocation src in breakpointList)
{
     if (src.StartLine == srcLoc.StartLine && src.EndLine == srcLoc.EndLine)
         {
                isBreakpointHit = true;     
         }
}

if (isBreakpointHit == true)
{
    resumeRuntimeFromHost.WaitOne();
}

where resumeRuntimeFromHost is a AutoResetEvent which is set when, F5 is pressed again:

 else if (e.Key == Key.F5)
{
    resumeRuntimeFromHost.Set();
}

The above code snippet is again in the OnKeyDown event handler where ‘e’ corresponds to the KeyEventArgs that captures the key pressed down.

I have attached the zip with these additions to the VisualWorkflowTracking sample. It essentially controls the breakpoint behavior in a re-hosted workflow application.

Please note that, it is not Re-hosted debugging per say since we are not controlling the Workflow Runtime through a customer debug engine. We are still taking the Tracking event data and using that for visualizing the activity being executed currently.

Thanks,

Kushal.

VisualTrackingWithStepService.zip

Comments

• Anonymous
  March 07, 2010
  very helpfull - thanks a lot!