locked
Question on WorkflowApplication class design ( Func Properties) RRS feed

  • Question

  •  

    Hi

     

    I found out that the Workflow Application class offers Func<T> properties to inject code for example when a error occurs.

    whats the reason behind the Design Decission of giving the WorkFlow Foundation class Func<T> properties instead of event?

     

    For Example

    public
    
     Func<WorkflowApplicationUnhandledExceptionEventArgs, UnhandledExceptionAction> OnUnhandledException { get
    
    ; set
    
    ; }

    http://msdn.microsoft.com/de-de/library/system.activities.workflowapplication.onunhandledexception.aspx

     

    or

    public
    
     Action<WorkflowApplicationCompletedEventArgs> Completed { get
    
    ; set
    
    ; }

    http://msdn.microsoft.com/de-de/library/system.activities.workflowapplication.completed.aspx

    Is it just to prevent the multiple receipients ?

    Or is it related to memory mangement due to fix pins caused by eventhandlers ? To be honest i must confess that i'm not sure wether Func<T> will created a fix pin in memory :-(

    I'm not sure about if this is good or not, but it would be very nice to get knowledge of the reason why this class is event free but has Func Properties.

     

    Monday, November 15, 2010 1:54 PM

Answers

  • Hi,

    These are single cast delegates and this enforces this (if it is set to a multicast delegate than an exception will be thrown). Events also have the sender parameter, but the WorkflowApplication is unusable during the callbacks, and so this parameter would not make sense if it were an event. The information needed to process the callbacks is passed int he different parameter types that are passed to different workflow lifecycle handlers.

    Is there a certain behavior that you needed from the old style events that you are not getting with the Actions/Funcs? If so we may be able to figure a way to get the desired behavior.

    Thanks,

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

     

    • Marked as answer by Gentlehag Tuesday, November 16, 2010 8:38 PM
    Tuesday, November 16, 2010 6:35 PM

All replies

  • Hi,

    These are single cast delegates and this enforces this (if it is set to a multicast delegate than an exception will be thrown). Events also have the sender parameter, but the WorkflowApplication is unusable during the callbacks, and so this parameter would not make sense if it were an event. The information needed to process the callbacks is passed int he different parameter types that are passed to different workflow lifecycle handlers.

    Is there a certain behavior that you needed from the old style events that you are not getting with the Actions/Funcs? If so we may be able to figure a way to get the desired behavior.

    Thanks,

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

     

    • Marked as answer by Gentlehag Tuesday, November 16, 2010 8:38 PM
    Tuesday, November 16, 2010 6:35 PM
  • Hi

     

    THanks for your reply. I was just interesseted :-)

    I assumed that it was to prevent the multicast delegate but was not sure :-)

    Tuesday, November 16, 2010 8:40 PM