>Hi Nick,
>
> I'm posting this as a new public thread so that others may benefit from the discussion. First of all, many congrats on your article in this month's FoxPro Advisor. I've been looking for a way of getting input from a client from a remote COM object for some time now, and just couldn't think of a way to do it. Your article was extremely thought-provoking, and will be the subject of our team's next brainstorming/VFP culture session.
>
> One thing struck me - namely, the definition of the Receiver/Responder pair of controls, the first being used to bind to VFPCOM, and the second to actually respond to the events.
>
> My first reaction was, why have two separate objects to do this? If the receiver needs to know of the responder's existence, doesn't that decrease object independence? Why not combine the two objects? Then I thought, ah, but what if you needed more than one Receiver/Responder couple, to respond to different sets of events?
>
> In this case, wouldn't it be possible/advisable to define the Receiver part of the equation in a base class, and have it call an empty Respond event (virtual function), which could be physically implemented in a subclass? Can you see anything wrong with this principle?
>
> Anyway, this is just a minor quibble which you'll probably shoot down in flames with something I haven't thought of. Many thanks again for a great article.
>
>Best wishes,
>Neil

Hi Neil,

You are absolutely right. It is up to the developer how to implement this. Receiver/Responder functionality can be combined in one control (which can be subclassed), or this functionality can be put right into the textbox class(as an example) which will be the Receiver/Responder and at the same time the control which visually reacts to the events. The textbox in ER2S2.SCX form is exactly this multi-purpose control.

Or, Receiver/Responder can be one control with more complicated DO CASE... or several Respond methods with different code, which control any of your existing form objects.

But, as I say in the article, this may not be convenient, if you want to implement this functionality into existing application, because then you will need to replace your textboxes with the textbox class which has SomethingHappened() method and can be bound to the events source.

I just separated Receiver and Responder functionality as a sample, to show several ways how this functionality can be implemented. So, my Receiver does only the receiving and then passes the info to the Responder that it knows of, and you might have several Responder objects with different code in Respond method. You can switch Responders on the fly, or remove/add as needed.

The main reason for separating Receiver and Responder functionality (especially for DCOM):

If they are separated, and you want to change the Responder for another one, you don't need to UnBindEvents and BindEvents again for the Receiver, which you will need to do in case if all functionality combined in a single control. Binding events over the Internet connection, for example, took me up to 40 seconds in tests. It is much faster on the local network, but still may take a couple of seconds.