Hi Mike,

I see Ken replied before I even saw this. FYI, Friday the 10th was my son's birthday, Saturday was my 12th anniversary, and today was Mother's Day....ay yi yi! :-)

To help clarify what he posted, in theory, COM isn't supposed to expose properties, so to get the value of a property you'd query Get_Property. If we did that internally within VFP, it might have unintended consequences.

So what we have here is a case of overly wishful documentation. Which will be addressed. I apologize for any inconveniences, but I hope you see the technical hurdle.




>This is a VFP Bug Report that applies to VFP 7.0 SP1.
>
>According to the VFP 7 Help file, the Locals Window of the VFP Debugger "Makes it possible for you to display all the variables, arrays, objects, and object members that are visible in a given program, procedure, or method." Unfortunately, this feature does not work for COM objects (ActiveX controls and OLE Automation servers), although VFP's Intellisense clearly shows that VFP possesses all of the necessary information. Not only is the Debugger's inability to reveal COM properties and member objects inconsistent with Intellisense, the Debugger is itself inconsistent as to which properties it chooses to display, and where.
>
>Taking Internet Explorer as an example, the Debugger displays only a subset of the WebBrowser.Document properties, which does not include the Document.Body object and the vast hierarchy of objects beneath that. While it is possible to display individual properties through the VFP Command Window, they must be requested one at a time, and even then they do not necessarily appear where they should in the Locals or Watch window, if at all.
>
>For example, I may be able to see x.document in the Locals window, but I don't see the x.document.charset property, even if I make an explicit reference to it. If I introduce a variable y = x.document, and then refer to y.charset, the Locals window shows the value of the y.charset property, but it still doesn't show that there exists an equivalent x.document.charset property! If I introduce a new variable, z = x.document.body, the Locals window initially shows nothing about the object z, and it still fails to reveal that there is an equivalent x.document.body object and a y.body object.
>
>Because of these problems, the VFP Debugger is of very limited use as a tool for studying actual instances of complex COM objects. This can only be accomplished by introducing dummy variables for each member object reference, and then going through the tedious process of explicitly referencing each property of every object one might wish to view. Even then the result is less than satisfactory, because the dummy object references have no visible connection to the object hierarchy as displayed in the Debugger.
>
>This is a most unfortunate limitation in the VFP Debugger, because there is no adequate alternative mechanism for examining the state of instantiated COM objects in VFP. While Intellisense, the Object Browser, and the Command Window are useful programming tools providing closely related functions, they are in no way a substitute for the Debugger's Locals and Watch windows.
>
>I urge you to give this problem the utmost priority. If the Debugger were fixed to work properly with COM objects, it would be a spectacular improvement to VFP. It is no exaggeration when I say that my expectation that this feature would work, was for me the single compelling reason for my recent upgrade to VFP 7.0. Needless to say, I am extremely disappointed that, despite authoritative assurances to the contrary, this feature does not work.
>
>(Also see UT Thread 654329 for related discussion.)
>
>Yours truly,
>
>Mike Asherman