>>Well in the Init() I envision BINDing events on a "permanent" basis. That is, for the duration of the app.
>>
>>But I'm imagining that there will (now, that we *can*) be times when one might want to change the BINDed events on-the-fly dependent on conditions. I'm looking for ideas to kind of 'centralize' such BINDing and UNBINDing. The best I can come up with is an aptly named method that does only that and I've gotta believe there's a better way.
>>
>
>Yeah, I see what you mean. You could put all of the intelligence in a BindEvents() method, but it could get pretty hefty. You could also create an event handler object, so that other objects could raise and bind to its events. That might be more flexible, but would leave the binding code decentralized.
>
>>No, because that seems to be wrong. It can be made to act that way though, using BINDEVENT() flags.
>>RAISEEVENT() seems to be nothing more or less that a different way to do a method call in another format. It has no relationship to a previously issued BINDEVENT(). The docs imply that there is something different (it uses the Activate event for its example) but it doesn't say what is actually different and I didn't get an answer when I asked about that.
>>
>>Does that muddy things up? < s >
>>
>
>Definitely. <g> If that is the case, I don't see many uses for RaiseEvent() either.

Have a look at thread #778310 (just for interest).
I can see one use for RAISEEVENTS() that to me is significant. It is clearer to the reader just what is afoot when reading the code (from an intentions/design point of view).


cheers