>>>>>>You are right about those features of CREATEOBJECTEX() and that CREATEOBJECT() also can be used for DCOM. But if the goal is, clearly, to create a COM object on the remote computer, what advantages gives me using CREATEOBJECT() instead of CREATEOBJECTEX() which is especially designed for this purpose?
>>>>>
>>>>>They are both for creating COM objects, the difference is that CREATEOBJECT() defers to the local registry to decide on what machine to run the object, CREATEOBJECTEX() uses the second parameter to decide. If you are using CliReg, you have already altered the registry to instruct the caller to instanciate the process on the remote box, so using CREATEOBJECTEX is redundant, and only confuses the matter, IMO.
>>>>
>>>>IMHO, calling CREATEOBJECTEX() is cleaner implementation, because in the code it is clear what you are doing,
>>>
>>>Or the code is 'bound' to one computer, where changing network configurations requires that you recompile...
>>
>>You don't need to recompile if you supply the data-driven parameters to CREATEOBJECTEX().
>
>_Now_ what's more complicated?
I believe to have it data-driven instead of hardcoding is not the actual complication, it's the way it should be designed in the first place.
Nick Neklioudov
Universal Thread Consultant
3 times Microsoft MVP - Visual FoxPro
"I have not failed. I've just found 10,000 ways that don't work." - Thomas Edison