>I am currently trying to use the AddProperty method of a Session Object to add properties dynamically at run time. When running my code in development mode the properties appear to be there. After compiling the code into a DLL the properties are not there. What's up with that? Heres some similar code
>DEFINE CLASS oMyobject AS SESSION OLEPUBLIC
>
> DIMENSION aRecordSet[2,4]
>
> PROCEDURE LOADCURSORS
> WITH THIS
> .aRecordSet[1,1] = "MYTABLE1"
> .aRecordSet[2,1] = "MYTABLE2"
> ENDWITH
> ENDPROC
>
> PROCEDURE LOADDE
> WITH THIS
> FOR i = 1 TO ALEN(.aRecordSet,1)
> .AddProperty(.aRecordSet[i,1]
> ENDFOR
> ENDWITH
> ENDPROC
>
>ENDDEFINE
>
>When running the DLL:
>ox = CREATEOBJECT("MYAPP.oMYOBJECT")
>ox.LoadCursors()
>ox.LoadDE()
>
>
>When running the development code:
>change the object from being olepublic then
>
>ox = CREATEOBJECT("oMYOBJECT")
>ox.LoadCursors()
>ox.LoadDE()
>
>In development properties appear in debugger
>in DLL properties should but do not appear in DLL

This is a little bit of speculation, because I have not played with it, but here is what I think is going on:

The way the VFP interacts with internal object is completely different than the way that it (or any other platform) deals with COM objects. The interface of a VFP COM object (it's exposed PEMs) are built into the Type library file when the library is compiled, and only updated when the library is recompiled. So while you might be able to add properties to COM objects, these properties will not be exposed because the calling environment has no way of knowing about them. When a COM object is instanciated through VFP, its available interface is queried only through the tlb.