Hi Mike,
I think your design is backwards. You have a method call that calls a UDF. One of my co-workers, Chris Bohling, created it as a UDF that calls a method. We use this sort of arrangement.
ObjectCreatedInTheCurrectDS = NewObjectX(ClassName, ClassLibrary)
FUNCTION NewObjectX(ClassName, ClassLibrary)
IF VARTYPE(ThisApp) = 'O'
ThisApp.OF(@m.Class,@m.ClassLibrary)
ENDIF
RETURN NewObject(m.ClassName, m.ClassLibrary)
The actually UDF carries more code to deal with parameters you might wish to pass the init, and default ClassLibraries and such, but this is the idea. I always shudder when someone says,"Let's pass the dataSessionID." I know there are those who do it all the time, but to me it seems wrong. Is it so hard to create objects in the dataSession to which they belong?
>Hey all
>
>Assuming we have a need to instantiate an object.
>
>SET CLASSLIB TO xxfwutil.vcx
>loSafety = CreateObject("cusPushPopOnOff","SAFETY")
>
>This code is too tightly coupled to the class. If I subclass that class or rearrange the vcxs, I'm in for major reworking.
>
>A factory object is a solution.
>
>loSafety = CreateObject(oFactory.GetClassName("SetResetOnOff"),"SAFETY")
>
>First problem: oFactory must have been instantiated someplace, probably with a segment like:
>
>PUBLIC oFactory
>set classlib to blah.vcx
>oFactory = Createobject("myfactory")
>
>It seems preferable to have a single table for the factory.
>
>I suppose I have a few choices:
>1 - If the application has a table, the factory class could be specified there.
>
>2 - I could have a UDF that instantiated the factory by looking in the same table. That seems like redundant code.
>
>3 - How about the factory object calls that same UDF?
>
>PUBLIC oFactory
>oFactory = CreateObject(UDFGetClassName("Factory"))
>.
>.
>.
>loSafety = oFactory.GetClassName("SetResetOnOff"),"SAFETY")
>
>and inside GetClassName...
>
>lparameters tcClassName
>lcClassName = UDFGetClassName(m.tcClassName)
>
>Any body see anything wrong with that?
>
>Thanks
Charlie