Gee,
Thanks Sergey,
You know me! I was fearing it was intentional and to help kill VFP by preventing VFP from competing with other back-end objects like ASP and ASP.NET, that can instantiate such objects. I guess M$ wants to protect us by dumbing down our code on a par with their NET boiler plate shops in New Delhi - how - how - egalitarian of Microsoft. They're saving us from ourselves - and their stock value certainly shows they've been making good decisions, in this regard, for the past several years.
Who can I write at Micro$oft (or at least mention in my prayers) for this salvation?
Usually program design causes application instability more than any rumored weakness in a product that has been working well since VFP 6. Leave it to the suits at Micro$oft to protect us from ourselves and rescue us from the denizen of "application instability".
I wonder, giving that instantiating objects inside a COM causes instability, if Micro$oft will be pulling that feature from it's other server objects. I hope so - we can't have application instability mucking things up - now can we!:-)
DO YOU REALLY BELIEVE THAT CORPORATE LINE OF BS? Well, at least we know one thing for sure: creativity still abounds around the shrimp buffet tables in Redmond!
Anther reason to move to Swing and a 64bit Java DBF engine!
>>>It's documented change in the behavior in VFP9: "The ability to have a property assignment set to instantiated object is no longer supported in a class definition and will generate an error".
>>
>>Sergey!
>>
>>What's the work around? Why did MS change it?
>
>AFAIK, it could cause application instability and crashes under some conditions.
Imagination is more important than knowledge