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