using EventHandler(Of TEventArgs) ?

[JohnH]

split thread from http://www.vbdotnetforums.com/vb-ne...ultiple-backgroundworkers-have-completed.html

BackgroundMultiWorker; nice addition, but I would add the DefaultEvent attribute to the class.
Any reason you defined three new delegates instead of defining the events as EventHandler(Of TEventArgs) ?

 

[jmcilhinney]

BackgroundMultiWorker; nice addition, but I would add the DefaultEvent attribute to the class.

Good idea. I'll do that.

Any reason you defined three new delegates instead of defining the events as EventHandler(Of TEventArgs) ?

Interesting that you should ask that as I was just discussing this topic with my boss this morning. As a rule, the generic EventHandler delegate should only be used internally. For events exposed outside the assembly they're declared in, it's considered best practice to define a specific delegate. Notice that no event in the .NET Framework is declared using that generic EventHandler delegate as its type.

 

[JohnH]

As a rule, the generic EventHandler delegate should only be used internally. For events exposed outside the assembly they're declared in, it's considered best practice to define a specific delegate. Notice that no event in the .NET Framework is declared using that generic EventHandler delegate as its type.

Don't know where you got that from, but that is not the practice in .Net library. You will only see that for old classes defined for .Net 2 or older. Classes in more recent .Net Framework versions use the EventHandler(Of TEventArgs) if it is not a very common handler, like RoutedEventHandler in WPF. For example looping through PresentationFramework assembly (.Net 3.0) I found lots of public events defined by the generic EventHandler. Same goes for System.Net (.Net 3.5), and there are examples in new classes for .Net 4 also.

 

[jmcilhinney]

I'm not sure either but I can assure you that I didn't just make it up. Perhaps the prevailing wisdom has changed. Apparently so.

 

[jmcilhinney]

While I don't recall if I was thinking this at the time, it occurred to me that I'm glad that I did choose to use custom delegates regardless because I wanted the BackgroundMultiWorker to parallel the BackgroundWorker as much as possible.

 

[JohnH]

While I don't recall if I was thinking this at the time, it occurred to me that I'm glad that I did choose to use custom delegates regardless because I wanted the BackgroundMultiWorker to parallel the BackgroundWorker as much as possible.

Not a valid point IMO, the BackgroundWorker class was written for .Net 2.0, so the developers didn't have access to that generic delegate at that point. I enumerated all assemblies in all Framework versions and found that in .Net 2.0 there was only two uses of the generic delegate, in one class from original .Net2.0 in Deployment assembly (probably one of the last additions), and in one class added to .Net 2.0 SP1. For .Net 3.0, 3.5 and 4.0 the generic delegate is used extensively throughout the assemblies. Speculating based on delegate usage, I think they would have used the generic delegate in Backgroundworker if they could.
It also doesn't break any user experience using the generic handler.