Mike;

You have to buy something and use it to know what it does. Just buy one of each and then you will know. You can take a leap of faith and just buy something.

Sometimes marketing hype says something that catches your eye but means something else.

I guess the best way to find out about anything is to ask a question and when it seems you have a correct answer you can act.

Perhaps marketing should learn a lesson from my English Professor. She always told us to write as if your audience knew nothing of the subject at hand. Sometimes we geeks "presume" too much and leave out important details. Why, doesn't everyone know what I know? :)

Tom


>Hi Larry,
>
>This is excellent! Of course even VFP6 had to understand what was in these runtime objects, since you could refer to them in code, but the debugger wasn't smart enough to make this stuff visible.
>
>The point I was trying to make to Ken is that this un-sexy sounding advance in the VFP debugger happens to be the thing that is, to me, by far the most significant reason to upgrade to VFP 7 without delay. I see from Bob Archer's comment that I'm not the only one who was surprised to learn about this crucial improvement.
>
>If Ken would like to speed up people's upgrading to VFP7, I would strongly suggest that he take another look at what's been written about the new features of VFP7. Somehow, this point seems to have slipped through the cracks. It is no exaggeration to say that this feature was the one and only compelling reason I personally felt for upgrading to VFP7 now.
>
>Mike
>
>>Mike,
>>The technology behind Intellisense is what makes querying/changing ActiveX object PEMs possible.
>>
>>VFP 7 is much better at querying the TypeLib or using the internal methods of the IDispatch interface to get object information. This technique is used when building the Intellisense window and it is used when expanding the object in the debugger.
>>
>>So yes you can expand an object at runtime and see everything about it.
>>
>>HTH.
>>
>>>>for inadequate documentation. This was never something I could get too excited about.
>>>>>
>>>>>On the other hand, it sounds like the improvements in VFP 7's debugger will make a huge difference in my ability to probe the complex world of ActiveX controls and OLE Automation. Where VFP 6's debugger just displays a single impenetrable (object), VFP 7 actually reveals the hairy underlying structure! Gadzooks, man, how could Microsoft fail to mention this? I feel like a blind man who has been trying to map out a forest by poking around with his cane.
>>>>>
>>>>>I hope this information will be helpful to your research on the reasons for people's delay in upgrading to VFP7. I would also hope that somehow you will find a way of adding this point conspicuously into some of the appropriate places that summarize what's new in VFP7. Intellisense may have a nice ring to it, but it's hard for me to see how any serious developer would fail to be vastly more interested in the improvements to VFP7's debugger. That's my 2 cents worth.
>>>>>
>>>>>Mike
>>>>
>>>>PMFJI - but, that's exactly what Intellisense lets you do (along with the Object Browser which works like the object browser in VB). It automatically pulls this info out of the components type libraries for you. It also lets you do this on against a web service running on a remote system. Very cool. You don't need to do this via the debugger, you can do it right from your code, or the command window. With the object browser addition you can do things like drag and drop an objects event list into a code window and VFP with automatically create the interface code for you (for binding COM events to VFP code). That's in addition to being able to browse objects in a treeview structure with all the comments for methods.
>>>
>>>Paul,
>>>
>>>Maybe I'm missing something in my understanding of this, but it seems to me that Intellisense is something like auto-completion on steroids. I.e. a feature that one uses during the process of writing programs, as opposed to a runtime debugging tool. Likewise, the impression I get about Object Browsers is that they operate against class libraries DLLs, etc. If these tools are somehow able to perform the role of a runtime debugger, it sure isn't clear from what I read about them. I'm not familiar with the VB Object Browser, but my vague impression is that what people call "Object Browsers" is something akin to VFP's Class Browser. This is nice, but it's not what I'm talking about.
>>>
>>>Did I misunderstand Vlad G's statement about being able to use the VFP 7 debugger to explore what's going on inside an instance of a WebBrowser control? He sure seemed to be stating pretty clearly that you can look into the Document object and see exactly what it contains. In VFP 6, all that the debugger shows is (object), and you can view no further. Does VFP 7's debugger reveal more? This is a runtime debugging question, not one about writing a new piece of method code.
>>>
>>>Mike