Since it appears that I may have tapped into something here, I offering up my comments, in un-edited form, my comments regarding Kevin McNeish's Events Article - which BTW, I thought was very good.

---

Just finished and digested your article on events in the January 2000 FPA. A very interesting technique indeed. However, I wonder if you are skirting some dangerous territory here. I think the events analogy is a good one, and, for lack of a better term in the VFP world, I think the word event works. What concerns me however is that you did not qualify the technique to the extent of how these "events" compare to other products that have the capability to both define and expose events as part of their interface and to raise those events at will. VFP's closest cousin, VB, has the ability to do this.

The big difference of course is that the VB events can be surfaced in anything that is both capable of hosting COM Components, and has the ability to respond to COM events. Thanks to VFPCOM, these COM Events can be surfaced in VFP. In terms of a pure VB interface, VB class modules themselves, can raise and expose events to a VB Form module or basic module that hosts an instance of that class.

And, I suppose this gets at the heart of my concern....

The approach you have taken, which by the way, works super in VFP , should be qualified that it will only work in a UI/Containership scenario. For example, lets say that I have a VFP custom class that needs to raise an event, or in reality, simulate an event to signal either the beginning of a process, the end of a process, or to provide a status during a process.Forgetting the COM stuff for a moment, how could I do this? The first question to ask here is "What about the host?" Is it capable of responding to events. When you look at how Visual Basic does things, it is quite elegant. In VB, when you use the WithEvents? clause when instancing a class, a code block in the host is provided to write the implementation code. The underlying VB class, which defines and fires the event, knows nothing about the host. For truly generic classes, this should be the case.

Now, lets contrast this with how we would need to do things in VFP:

If the class needed to somehow communicate with it's host, it would need to invoke a method of it's host. This means the class would need to know something about its host's interface. There are a variety of ways you could do this with setting some properties and invoking some macro expansion. In any case, it represents a
"tight-coupling" between client and server. Of course, when it comes to passing arguments to events, using this methodology could be quite challenging. Contrast this with real events, which are fired independently of knowledge of it's host and the ease of passing arguments, a big difference exists.

When dealing in the realm of the VFP form/class designer, the task is somewhat do-able. However, what happens when I have a class and I wish to use AddObject() instead. Yes, the access/assign methods still fire. However, I have lost the ability to attach code. When I add an object to the form via drag/drop from the form controls toolbar, I then have the ability to attach code. In VB, where the notion of events are fully supported, this limitation does not exist.

So, is it my intention to rain on your parade here?
No...
Does you methodology work well in the confines of a VFP UI?
Yes, your methodology works extremely well in the confines of a VFP UI, and makes for a great messaging strategy...
Is it a kludge?
Yes. Given that you are using a mechanism for setting properties for many objects in one command line, and as a consequence, having an assign method invoked, is a kludge. But, it is a nice kludge!!!! :)

Should your use of the word event be qualified
Yes, it should be. When you compare with the rest of Visual Studio, Visual Basic in particular, on how events are manifested, it is clear that while the results are seemingly the same, the path to get there is very different. And, when you begin to examine that different path, the limitations on the VFP side become quite evident.

In closing , I would just like to say when it comes to inheritance, we expect the VB folks to qualify their statements with the fact that they simulate inheritance. In this case, we are simulating events. And, because the events are simulated, limitations do in fact exist where they do not in situations where events are fully supported.

So...it is a great article, a nice methodology for VFP UI's, but one that needs to be qualified with respect to how other tools that fully support events.