Menu
while working with WF 4.0 I noticed that the WorkflowApplication class exposes action properties (Aborted, Complete, etc...) instead of events. Is there a specific reason? When should I prefer action properties instead of events?
Thank you
435
In programming, an event handler is a callback routine that operates asynchronously once an event takes place. It dictates the action that follows the event. The programmer writes a code for this action to take place. An event is an action that takes place when a user interacts with a program.
Events are typically used to signal user actions such as button clicks or menu selections in graphical user interfaces. When an event has multiple subscribers, the event handlers are invoked synchronously when an event is raised. To invoke events asynchronously, see Calling Synchronous Methods Asynchronously.
Steps for creating and calling the event: The event is an instance of a delegate. Since an event is an instance of a delegate, then we have to first define the delegate. Assign the method / methods to be executed when the event is fired (Calling the delegate) Fire the event (Call the delegate)
Use the EventHandler delegate for all events that don't include event data. Use the EventHandler<TEventArgs> delegate for events that include data about the event. These delegates have no return type value and take two parameters (an object for the source of the event and an object for event data).
Wow; I see what you mean; that really surprises me.
However, if you can't think of a good reason to use properties here (and I can't), then stick to events; they avoid a range of problems (accidental unsubscription and inappropriate invocation being the biggest).
The only thing I can think of is that maybe they needed this for serialization purposes, but I can think of other ways to crack that nut. Alternatively, maybe regular events don't make sense in the crazy "dependency property" / "attached property" / "routed event" world of WF.
63
Edit: the following isn't accurate, see Marc's comment below.
For one thing, events allow multiple handlers inherently while an Action property only allows a single handler. Yes, the Action property could do a broadcast itself, but that isn't very cohesive or idiomatic.
I'm with Marc on this one, I'm surprised they used Action properties instead of standard events.
25
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
