>This is an idle comment. While I agree with David's point about the unreliability of undocumented features, I don't know that the one under discussion is any more unpredictable than any that _are_ documented. IOW, I can see good reasons for the object to have this behavior. Perhaps, it could be made "official?"
>
>>>I've seen one person using it as an attempt to get "static" properties for all objects of a given class. I'm not sure you can count on this "undocumented" behavior exisiting for the rest of VFP's lifetime.

Sure, just like we have all the white papers on internal works of buffers, Rushmore, views, grids, combos, ... did I forget something? Actually, we don't need all the inner workings (what would we do with megabytes of source?), but actually we need guaranteed behaviors, which we don't have, and probably can't. Fox (in all versions) is complex enough to be beyond any deveolpment team's capacity of thorough testing. There's always a chance some developer somewhere will force it into an unknown corner. So, the best approach so far is the trial & error, which probably takes up less time than reading all the source (if we had it).

The logic to all this seems to be that the constant properties are evaluated at compile time, and function properties are evaluated at first instantiation time. I've actually tried to assign a variable to a property (a variable which is always present, it's one of the few globals I keep always at hand), and it surprised me to see it behave like a constant, i.e. the value it had at compilation. I wander if I substituted it for a function which returns the same variable, what will happen.

But, as David said, the today's mechanism of instantiation behaves like that, and maybe it does in 6.0, but who can tell of 7.0 or whatever. We can't rely on that.