I'm going to take you up on that, Sergey!
Thanks!
>Hi Terry,
>
>My guess id that it has something to do with VFP caching of classes. If you can put together some code that reproduces this problem, I would be happy to test it in VFP8beta for you.
>
>>I add many of my activex controls through a PRG. Eg, DEFINE CLASS and the oform.addobject via the containers init event to put it on the form.
>>
>>I haven't noticed any problems -and I only bring it up because VFP 7 not only uppercases the OCX's property/method names, but also colors the property/method content information (in the visual class properties sheet) for those non default settings assigned in the DEFINE CLASS or addobject method. VFP 6 just uppercased the 'modified property/method names.
>>
>>To replicate, define an OCX in code (like a treeview) and attach it to a form. Then run the form. CLose the form and CREATE a visual scratch form. Drop a treeview onto the form (visually) from the activex control palette.
>>
>>Look at the property/method sheet for the 'visual' tree view. The names and assignments (w/VFP 7) are upper cased , as opposed to the proper case of the properties that remained at default (not assigned by DEFINE CLASS or addobject).
>>
>>Is this a feature? The only way to flush the reminants of the PRG, from the visual class property sheet, seems to be to restart VFP. Is there a command line service to clean out these residuals from PRG classes?
>>
>>TT