Reply to thread

Message: [QUOTE="Peter Duniho, post: 13868397"] I don't understand what you mean by "why did it work in the article". The article doesn't, as near as I can tell, provide a complete code example. The code in the article _doesn't_ work, at all. Not unless you add something to it. One of the commenters to the article has already pointed out how to get the delegate type from outside the containing class (i.e. qualify the type name with the name of the containing class, as in "Car.OwnerChangedEventHandler"), and perhaps you already understand that part. But asking why the code works in the article doesn't make any sense to me. It _couldn't_ work as posted unless the code was referencing the type from within the Car class itself (*), and the code in the article doesn't work in any case (since it's not complete). Pete (*) Actually, that statement isn't really true. It's true enough, given what code was available in the example. But as long as we're assuming arbitrary code added to the example to make it work, we could actually assume the code includes a "using" directive to define a type alias. So, you could have code that looks like this: using System; using CustomEvents; using OwnerChangedEventHandler = CustomEvents.Car.OwnerChangedEventHandler; namespace Test { static void Main(string[] args) { Car car = new Car(); car.OwnerChanged += new OwnerChangedEventHandler(car_OwnerChanged); } static void car_OwnerChanged(string newOwner) { } } And for that matter, you could side-step the entire issue by letting the compiler infer the type and instantiate the delegate for you: using System; using CustomEvents; namespace Test { static void Main(string[] args) { Car car = new Car(); car.OwnerChanged += car_OwnerChanged; } static void car_OwnerChanged(string newOwner) { } } If you never actually have to write the type name, then of course it doesn't matter whether you know how to write it correctly. :) [/QUOTE]

Verification