Hi Agnes

A couple of point might make things a little clearer.

I can create a container object or any object that is derived from one of the base classes and add them to my form from within the DLL.

With interface "parameter forms" doing it programatically is cumbersome so I want to use my own class library where I can do it visually. In addition to this I have a number of existing class libraries I would like to be able to use. I am trying to figure out how VFP handles things with DLLs.

The problem, as this thread shows, which occurs when I want to use my own class library to instantiate objects contained in my class, is that I cant seem to discover the right code that will 'find' a class definition that I have compiled into my DLL. It doesn't matter whether I use the full path to my DLL or not it fails.

If I create an APP or an EXE (or point to the class library directly) it works fine but I then have a DLL and another executable (or class library). I am trying to just have one file to handle everything with respect to a particular interface, including objects that get added to various forms in my containing application. I can do that with APP's & EXE's but not DLL's.

The idea is that the containing application will remain stable and does not need to be changed AT ALL when I add new interfaces, which happens regularly. The whole thing is controlled by data settings.

I had hoped to figure out single threaded DLL's and then move onto multi-threaded DLL's but cant seem to and easy way around the issue of using my own class libraries with DLL's

regards
Geoff Scott


>Hi Geoff,
>I still have my problems in understanding.
>I assume you run an exe and try to extract a class from an dll
>
>I would use NewObject function as
>NEWOBJECT(cClass[,cModule[,cInApp[,Para]]]) where cInApp is the Application (exe) with complete path, cModule the vcx or prg within cModule and cClass is the Name of the class within cModule
>NewObject method is similar.
>
>AFAIK the extraction of classes out of an dll will fail, but I have never tested.
>
>In
>>

>>DEFINE CLASS Interface AS CUSTOM OLEPUBLIC
>>
>>PROCEDURE InterInit
>>PARAMETERS pForm as Form
>>	SET CLASSLIB TO Attaché.vcx
>>	WITH pForm
>>		.NewObject('InterOpts','interopt',"Attaché.vcx",'d1.dll')
>>		.myContainer.visible=.T.
>>	ENDWITH
>>	RETURN 'InterOpts'
>>ENDPROC
>>ENDDEFINE
>>

>
>the Line
>> SET CLASSLIB TO Attaché.vcx
>is of no help, because it sets classlib to an vcx that is compiled to the exe or in path. SET CLASSLIB looks easy but check help to see the tricky things on what comes in which order
>
>We know exactly that we will create pform.InterOpts as an instance of class interopt from classlib Attaché.vcx out of application d1.dll, so avoid set classlib
>
>BTW avaoid character é in the name, it is allways better to use old fashioned DOS naming conventions, at least no spaces and no exotic characters as é or ü. It only will cause trouble.
>
>Anyway, give "d1.dll" complete path.
>
>On the other hand, as I understand your message, you have a dll that uses class interopt for one or other reason.
>
>You create a instance of the same class in your exe. This is not the same object as in your dll, it is part of the form.
>
>So why not include the Attaché.vcx to both the dll and the exe project and instanciate it inside the form (of the exe) with simple.
>
>

>.NewObject('InterOpts','interopt',"Attaché.vcx")
>

>?
>
>The exe will be a little bit bigger and you need to ship both if you change the Attaché.vcx, but it will work.
>
>
>HTH
>
>Agnes