>I just talked to Calvin Hsia about this, he is our lead developer on the Fox team at Microsoft. This is not a bug, this is by design. Or more to the point, a limitation with COM object instances their interfaces. In COM, there is no such thing as a property. Everything is a method call. For the “property” foo, there are 2 methods: get_foo() and set_foo(). In order to do what you are requesting, the actual COM object property get_ would have to be invoked, which can have side-effects. The author of the server could run *any* code in these methods, which could change the state of the COM object.
>
>The VFP debugger (or any COM debugger) cannot change the behavior of the object being inspected. The VFP debugger does not make method calls to retrieve values. IntelliSense on COM objects works by interpreting COM TypeInfo which can be provided statically using a type library or provided dynamically by the server. This is not a bug in the IE WebBrowser control either, it is by design as per the interface define in the class used for that control. This explanation explains why you see slightly different behavior in the debugger and IntelliSense with various COM object instances.

Hi Ken,

Thank you very much for your prompt reply and taking Calvin Hsia's time to inquire about this. I'm sure Calvin is very busy working on important improvements to VFP, but I don't think his time spent on this issue is wasted. Your explanation about the reasons for the Debugger's present behavior is helpful and informative.

It may be that the way COM objects are displayed in the Debugger is "by design", but I think it's also arguable that there are bugs here, and I question the validity of some of your statements. First of all, please note the VFP 7 Help file excerpt that I began with:

[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.

If there is some major exception to this statement for the case of COM objects, I think you are obliged at least to correct the documentation. Now, I'm not proposing that you simply add such wording, only pointing out that the discrepancy qualifies this behavior as a bug.

Another problem that I noted is the Debugger's failure to display COM properties and members in the proper place, even after an explicit reference to an item has been made through code (or via the command window). I don't think anything you've said justifies that omission, which I also regard as a bug.

While it's interesting that the underlying implementation of COM is based entirely on method calls, I don't think this detail necessitates the Debugger's concealment of COM "properties", member objects, collections, etc. After all, Intellisense and the Object Browser are able to discriminate between methods and other types of things, even if these other constructs happen to be implemented through methods. Furthermore, Microsoft's extensive documentation of COM interfaces in MSDN relies heavily on these concepts, so there is clearly an established level of abstraction that frees us from being concerned with the underlying implementation details you allude to. Of course, that doesn't mean everyone is free to ignore such details, and your explanation helps to clarify why a fix may require more of Calvin's effort than one might have imagined.

As to your point about violating the principle that the Debugger must be free of side-effects, there already exists a very big exception to this claim: the Watch window. For example, if I start with an IE object reference in x, with none of x's properties displayed in the Locals window, I can enter an expression like x.document.charset or x.document.body.bottomMargin directly into the Watch window and immediately see the value of this property. However, in each of these cases, the the locals window fails to display the properties that have already been obtained to satisfy the Watch window request. So there is no issue of additional side-effects here, and the entire purpose of the Watch window, to display requested values that are visible to the program, must surely take precedence over the general principle of minimizing unnecessary side-effects.

Understanding that typing an expression into the Watch window is just an explicit request to display a value, whatever it takes to get it, doesn't it also make sense in the case of object references to permit the user to simply say "show me the next level of properties and members" by deliberately expanding a node of the treeview? Of course this is not the current behavior in most cases, but I don't think there is a valid argument against it on the grounds of introducing undesirable side-effects. The central issue here is not whether we should consider this a bug fix or an enhancement, but to recognize that this is an extremely desirable and achievable capability. What's more, unlike numerous other requested fixes and enhancements, there is no satifactory workaround to this serious failing in the VFP Debugger. Perhaps you might wish to introduce a new SET command or SYS() function, if you think such a feature should be optional, but I can tell you that I would be content to always have the proper, complete display of object properties enabled. Another possibility would be to treat the Watch window and the Locals windows as separately configurable in this regard, but again, I'd be content to always do as the present documentation states, which is to display all properties and members that are visible to the program.

Speaking of other COM debuggers, it is my understanding that VB6 has no such restrictions on its ability to display and navigate COM objects, so I don't see how your assertion can be correct about the impossibility of providing a comparable level of COM support in VFP. As you noted, Intellisense and the Object Browser are driven by essentially static information, and therefore these capabilities are quite different from the Debugger, which is an inherently dynamic facility. While I don't wish to disparage these other fine features, it is a striking incongruity that in a language as dynamic as VFP, especially with its recent enhancements aimed at improving COM support, the Debugger should be so lame in its COM support. Given the choice, I would without hesitation have chosen to fix the Debugger over providing these other less essential capabilities. I feel another metaphor coming on: you've given us power windows and leather upholstery, but I'd rather have the beat-up '56 chevy that also can run in reverse. Of course, the best thing would be to have it all, and the work that has already been done on Intellisense et al should mesh very well with much-needed COM support in the VFP Debugger.

There is no doubt that VFP's support for ActiveX and OLE Automation is a major strength of the product, and recent enhancements incorporated into VFP 7.0 were a significant and welcome addition to VFP's arsenal. As people become increasingly aware of the importance of COM integration, I think you will hear from more and more who find themselves befuddled by the weaknesses of the VFP Debugger. Among those who have already delved into this area, I'm sure you would find very strong support for the fixes I'm requesting. For those who have not yet gotten into COM, you would be doing them and Microsoft a very great service by fixing these problems before they become a source of further confusion and irritation.

Thanks again for your attention, Ken.

Mike