Hi Jim,

I will probably create a custom BindEvents() method in my form class that is called by Init(). That is just to make it more evident where the event binding code is. This puts the responsibility on the form to take care of interactions between its controls, and I like that.

I'm not sure I follow your thinking with avoiding RaiseEvent() in classes. I guess my most common use of it will be to report the progress of the current operation, but I'm talking business logic now. In that scenario, the event binding code would probably be in a custom form method. MyForm.DoProcess() would do something like:

- Create business process object
- Open thermometer form
- Bind business object UpdateProgress() event to thermometer Update()
- Start the process on the business object


>The new event binding features look like they will be very useful.
>After a little bit of playing with them in dinky tests I think I understand how they operate and when I might use them.
>The big outstanding question that I have is: Where should they be coded?... Is there some optimal place(s) to put the code to make their existence/usage evident to future code readers? I can see usage being worse than "spaghetti code" if I am not careful about it.
>
>My answer to when it should be useful is: in the general case, outside of classes, with perhaps some empty methods coded within classes to facilitate usage of BINDEVENT() externally. And I don't think that RAISEEVENT() has any place within class code at all. Does this make sense or is it cutting off valuable potential uses?
>
>But I can't settle on a good answer for where the code should go, and maybe there is no ideal place.
>I'm inclined to say that Form Init() is the logical place for BINDEVENT() code. But what of the case where one might want to dynamically BIND/UNBIND an event? Should there be some 'standard' for such usage, and if so, where?
>
>Opinions?