Hi!

>I am curious about how VFP handles things behind the scenes when you're using OOP. When you instantiate an object, where are all the methods and properties and properties stored? I would think, since VFP tends to construct most of its higher level operations on tables, that it wouldn't be necessary to load all these elements into memory, that object instantiation would simply involve setting pointers to the existing VCX table.
>

I guess no, the object is in the memory after instantiation. More, the VCX is also loaded into the memory during any object of that class instantiation. However, next time another object of that class is instantiated, the template from memory is NOT used. Try it on a simple sample. Create a Label class and set up as a value of the Caption property a function call ("=MyFunc()"). Make a PRG file with MyFinc and show messagebox in that function to indicate that it is called. Set this PRG as a procedure file. Set the VCX file by SET CLASSLIB. Use createobject or _Screen.AddObject to create label object of test class. First time you create it messagebox must appear. When you create second object of that class, messagebox must appear from the logical point of view to calcualte caption for another label. If it is cached, application logic will be broken at this moment because function is not called. Anyway, when you put such label on the form in design time first time, messagebox appears. Next time it does not appear, so I afraid I could be not correct. Just test it if you have time.

>This is an important issue when you evaluate the advantages of using COM objects vs. native objects with VFP. In Mike Myer's article in FPA (Oct 2000), he makes a good point of how important it is to keep COM objects slim, to keep your overhead low (and having to load everything into RAM)...but I would tend to that VFP's native objects would have an advantage here because of the lower overhead.
>

Overhead here is lower in any case. There is a lot of overhead with COM objects when loading them related to work with interfaces and initialization. Some FP objects are really quick and take very little of memory. Take a look to the article at the fox.wikis.com that compare memory usage for different VFP objects (do not have a link handy).

>It would be helpful to have an expert opinion here.