October 26, 2005 fun

I’m all ready for 9th grade

You Passed 8th Grade Math
Congratulations, you got 9/10 correct!
Could You Pass 8th Grade Math?
October 24, 2005

PDC05 Sessions Online

Mike Swanson and the folks that made this possible, you guys rock!

If you were unable to attend the Microsoft Professional Developers Conference 2005 (PDC05) in Los Angeles this year, never fear; 209 breakout sessions, panels, and symposia are now available online. Each session includes a video of the presenter, a navigable index of the content, the PowerPoint presentation itself, and video of any demos. We’ll be hosting this content for free, for anyone, for six full months.”

October 24, 2005 .net

WF Activity Context

October 24, 2005 .net

Typed WF Communications Details

October 24, 2005

Petzold on “Does Visual Studio Rot the Mind?”

I’m really loving having Mr. Petzold in the blogesphere. His latest essay has the following abstract:

Visual Studio can be one of the programmer’s best friends, but over the years it has become increasingly pushy, domineering, and suffering from unsettling control issues. Should we just surrender to Visual Studio’s insistence on writing our code for us? Or is Visual Studio sapping our programming intelligence rather than augmenting it? This talk dissects the code generated by Visual Studio; analyzes the appalling programming practices it perpetuates; rhapsodizes about the joys, frustrations, and satisfactions of unassisted coding; and speculates about the radical changes that Avalon will bring.

It doesn’t end the way I expected it to. Fun stuff.

October 24, 2005 spout

WF Activity Context

I was playing around with a state machine workflow in WF and ran across something that I didn’t except. Apparently if you have a an activity that can be other than a singleton, e.g. inside of a loop or as part of a state machine workflow, then an activity can not be accessed by it’s workflow instance variable. For example, the following works just fine in a sequence workflow:

public partial class Workflow2 : SequentialWorkflow {
private void code1_ExecuteCode(object sender, EventArgs e) {
// Retrieve Comment property from typed event sink (generated by wca)
string comment = this.eventSink1.Comment;
    Console.WriteLine("Order approved w/ comment= {0}", comment);
  }
}

However, in the case where the activity can be executed more than once, it’s my understand that each time through, there’s a new activity object that’s different from the named activity associated with the workflow. To get a hold of the current activity, you have to traverse the activity tree, which you can access in a code activity via the sender’s parent property:

public partial class StateMachine1 : StateMachineWorkflow {
void code2_ExecuteCode(object sender, EventArgs e) {
// Retrieve Comment property from typed event sink (generated by wca)
    Code codeActivity = (Code)sender;
    IOrderService_Events.OrderApproved eventSink2 =
      (IOrderService_Events.OrderApproved)(codeActivity.Parent.Activities["eventSink1"]);
    string comment = eventSink2.Comment; // eventSink1.Comment will be unbound
    Console.WriteLine("order approved w/ comment= {0}", comment);
  }
}

I haven’t figured out whether this makes sense to me yet, but that’s how it is. You can get the code here.

October 24, 2005 spout

Typed WF Communications Details

If you downloaded the samples from my previous two forays into WF communications programming, you probably couldn’t get them to build. The problem is that when I packaged things up, I removed the bin directories. I haven’t figured out just why this causes everything to stop building, but with the help of Dennis Pilarinos, I rearranged the two projects into three:

  1. communications interface (CommunicationLibrary): the data exchange service interface definition, compiles into CommunicationLibrary.dll

  2. communications activities (WorkflowProject1): uses a pre-build step to generate the typed activities generated from the communications library using the wca tool, references CommunicationLibrary.dll and compiles into WorkflowProject1.dll (nice name, eh? : )

  3. application (EventSinkAndMethodInvoke2): the app that uses the typed activities, references both CommunicationLibrary.dll and WorkflowProject1.dll

It’s only by separating the communications activities into a separate assembly that things can build and rebuild reliably. You can download the newly configured code here. Enjoy.

October 22, 2005 fun

Samwise Gamgee was the ultimate Program Manager

That is all.

← Newer Entries Older Entries →