Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Computer name and CREATEOBJECTEX()
Message
General information
Forum:
Visual FoxPro
Category:
Classes - VCX
Miscellaneous
Thread ID:
00771842
Message ID:
00772668
Views:
15
Geoff,

Another approach that would simplify the creation of server sided COM objects is to use a classfactory object to create the objects. This is a very small com dll that is installed on the server and can be called from each client (depending on how you choose, either by CLSID or by registering locally on each pc). Then you call the CreateClass method in order to create other COM objects on the server. This way you don't need to have each COM dll registered on the client since the actual creation of the object happens on the server and the object is then passed back to the client.

The ClassFactory really only needs 1 method, the CreateClass() method, however we also use this object from our SQL Server machines to access COM objects across the network so we also have a CreateClassEx method since SQL server cannot handle creation of distributed objects.

Here's the code:
DEFINE CLASS ClassFactory AS Session OLEPUBLIC
	PROCEDURE CreateClass (lcClassName)
	RETURN CREATEOBJECT(lcClassName)
	ENDPROC

	PROCEDURE CreateClassEx (lcClassName, lcServer)
	RETURN CREATEOBJECTEX(lcClassName, lcServer)
	ENDPROC
ENDDEFINE
Kurt
>Ouch!!!
>
>My project has 18 sub projects (one for each accounting interface), all of which are very similar. Each has a number of different objects which are used by the main project. Under this method I would have to load each of the CLSID's into my main project which is not very dynamic or flexible.
>
>It is simpler, I think, to trap the inital creation and if creation fails register the DLL on the local pc on the fly then load the other components as needed. Given that most of our clients will only ever use one accounting interface they will only have one DLL registered.
>
>I was loading them via NEWOBJECT from an EXE because if I compile them into a DLL then NEWOBJECT wont find them (dont know why). I am wanting to protect them a bit because of curious users by creating them as DLL's.
>
>Also, some components are only loaded if the main app/project is run on the computer which the app was initially installed.
>
>I think I will try the register on the fly technique.
>
>Regards
>Geoff Scott
>
>>Geoff,
>>
>>In order to call a remote dll (COM object), windows will look up the class id of the dll in the local pc's registry, even though the object is installed on another pc or server. The work around for this is to call the CREATEOBJECTEX function with the class id instead of the class name. Look in the folder where you compiled the .dll and there should be a .vbr file. Open this file and look the line that resembles this:
>>
>>HKEY_CLASSES_ROOT\dllname.objectname\CLSID = {some CLSID string}
>>
>>Use the CLSID string in your code such as:
>>
>>loObject2 = CREATEOBJECTEX('{some CLSID string}','YOTTA')
>>
>>
>>This should work as long as the dll is registered on the YOTTA pc, and you should be able to call it from any other pc on the network.
>>
>>Hope this helps,
>>Kurt
>>>Yes.
>>>
>>>The command I used was
>>>
>>>
regsvr32 "S:\PC Source\SalesLink 3.1.0\test\myproject.dll"
>>>
>>>where "S:" is a network drive.
>>>
>>>you said I should put
>>>
>>>
regsvr32 \\YOTTA\Path\YourDLL.DLL
>>>
>>>but I cannot put
>>>
>>>
regsvr32 "\\YOTTA\S:\PC Source\SalesLink 3.1.0\test\myproject.dll"  or
>>>regsvr32 "\\YOTTA\PC Source\SalesLink 3.1.0\test\myproject.dll"
>>>
>>>because regsvr32 cannot locate the DLL.
>>>
>>>The object is registered because I can create it using CREATEOBJECT(). At this stage I am doing everything locally.
>>>
>>>Regards
>>>Geoff Scott
>>>
>>>
>>>>Did you tried registering the class how i mentioned with regsvr32
>>>>
>>>>the problem is that when you try to create an obeject from a DLL that resides in a Server, the createobject searches in the local windows registry a DLL entry which is located in a directory named "SERVER".
>>>>
>>>>Every ActiveX DLL that you want to access has to be registered, if you have a ActiveX DLL in your PC, in order to use it you have to register it, the same with a ActiveX DLL that resides in a remote server, regardedless if they have or not the same name, windows will create a unique name for both of them.
Previous
Reply
Map
View

Click here to load this message in the networking platform