Tom Clarkson

The workflow I have been working on includes some delay activities. It was difficult enough getting them to run at all using the ManualSchedulerService (I think UseActiveTimers fixed that issue), but now that I get into some more complete testing I notice that the timeouts (set in the InitializeTimeoutDuration event) aren’t behaving as expected.

The event handlers were something like this:

  private void delayComputronUpdate_InitializeTimeoutDuration(object sender, EventArgs e)

        {

            if (DateTime.Now.TimeOfDay < Constants.ComputronUpdateTime)

            {

                delayComputronUpdate.TimeoutDuration = DateTime.Today + Constants.ComputronUpdateTime – DateTime.Now;

            }

            else

            {

                delayComputronUpdate.TimeoutDuration = DateTime.Today.AddDays(1) + Constants.ComputronUpdateTime – DateTime.Now;

            }

        }

There aren’t any errors produced, but the timer event doesn’t execute at the expected time. The problem turns out to be that even though the event is only ever set on delayComputronUpdate, sender is something else. ((DelayActivity)sender).TimeoutDuration is completely different to delayComputronUpdate.TimeoutDuration. If you don’t use the sender, the delay activity will use the default timeout – easy enough to detect if it is zero, but the difference between two days and two business days isn’t likely to be noticed during development.

The fixed code:

        private void delayComputronUpdate_InitializeTimeoutDuration(object sender, EventArgs e)

        {

            if (DateTime.Now.TimeOfDay < Constants.ComputronUpdateTime)

            {

                ((DelayActivity)sender).TimeoutDuration = DateTime.Today + Constants.ComputronUpdateTime – DateTime.Now;

            }

            else

            {

                ((DelayActivity)sender).TimeoutDuration = DateTime.Today.AddDays(1) + Constants.ComputronUpdateTime – DateTime.Now;

            }

        }