Jeff,

>I don't know where you guys get the idea that RaiseEvent() is a requirement for good class design when utilizing BindEvent().

Actually I never did before today <s>.

But I already had come to believe in what is the essence of much of Mike's argument--that if your overall design contemplates event binding, there are both good and practices available, and it can be very easy to create a class design that hides this reality. Where our design has evolved is toward planning for this binding, but we were not using RaiseEvent(). Instead our classes have methods "intended to be bound to" and these consist of both naming and comments that make the idea pretty obvious. But once you get to that point, it seems that your only a short step from Mike's approach, so I figure why not?

That said, I don't see any technical reason that you must switch to RaiseEvent() as long as your design is obvious enough. RaiseEvent() does provide some flexibility in allowing the same method to be called via other mechanisms without triggering delegate code, I suppose, but we've not yet encountered a use case demanding this.

Aside: The reason we got close to this in the first place is because of not being able to bind to methods where strings are passed by reference in VFP. This was a potential deal-breaker for some heavy text processing we were doing, so we've reverted to creating a token Empty object as the payload, and simply adding a few simple properties to pass around. This is much like the object in Mike's example. And it turns out to be a very flexible design when you suddenly want to add new features.

Regards,

-- Randy