I'm no COM guru, but I've been reading alot about it to pass the DEFINING ARCHITECTURES exam. It would seem like changing the interface of an COM server would drive the system crazy. Doesn't registering the DLL actually tell the system which interface (i.e. properties) to expect? If those are different, I wonder if that causes an explosion. (I'll bet Rick Strahl could answer this question.)

Until then, you may try a different approach. Make the properties of your DLL fixed but have it create a referenced object that holds the record you're looking at. You could use SCATTER NAME to get the object built for you.

Something like:

DEFINE CLASS Foo AS Custom OLEPUBLIC

  PropertyOne = "One"
  PropertyTwo = "Two"
  oStructure = .NULL.

  PROCEDURE Init

    -- open the table and navigate to the right record
    SCATTER NAME This.oStructure
  ENDPROC

 
  PROCEDURE ReturnValue
  LPARAMETER cProperty
    -- check for errors with PEMSTATUS
    cStructureProp = "This.oStructure." + cProperty
    RETURN &cStructureProp
  ENDPROC

ENDDEFINE

Assuming your calling program actually knows the names of the properties it's looking for, you'd call it like:

ox = CREATEOBJECT("Foo")
?ox.ReturnValue("FirstName")



I don't have time to mock this up and see if it works. I may have a bug up there somewhere. I usually do! :-)

HTH,
Marty