>>In order to access properties of objects that are in and of themselves properties of a parent object, you first have to call the _Get method of the parent object's property. This could lead to the side-effects that Ken (and indirectly Calvin) posted about.
>>
>>Your suggestion of simply listing the properties gleaned from the Typelib raises the question of what would be used as the values for the properties and how would the developer signal the debugger that a specific property should actually be queried for its value.
>
>I'd suggest simply no values - just as VFP does now for members which are .null.; so their names would be shown. If anyone wanted to know the value, they could simply drag the property to the watch window, and cause whatever behavior to occur from there - and also get the value.
>

Hi Dragan,
Displaying Null actually implies that the value was queried and it was a Null value. To be more in line with what you wanting (drag and drop), it would show nothing at all. No quotes, no "NULL", simply nothing.

>>I just entered a new entry in the Toledo Wish list, ID 582. It requests that Intellisense be available when a developer is defining Watch variables. I think this is a compromise between what you are asking for and the rules that the VFP Team want to impose. Your comments would be appreciated.
>
>Pretty much along the same lines with what I just said - and I would actually like to see both things happen: intellisense in the watch window, and properties in the local window (without values) draggable into the watch window.
>
>Besides, some properties DO appear in the locals window, probably with last value observed. That's OK IMO, just needs documenting in debugger help.

Yes, first-level (parent object) values that have been queried explicitly by the user seem to be cached and that value is displayed in the debugger. And I agree that it should be explained in more detail in the help somewhere.

Regards.