I have a COM object that accept a string and return it reversed.(ex:"hello"->"olleh").

This script work well under W98 but not under NT 4.

Any suggestions ?

Thanks.

************************
Break On
$Obj = OleCreateObject("SERVEUR001.REVERSE")
? "Txt : "
Gets $Txt
$Ret = OleCallFunc($Obj, "REV_STR", "s", $Txt )
? "Reverse = $Ret"
?
exit
************************

Obviously - this is a custom Automation object you wrote in-house ?

Ok - first thing to do is display the value of $obj ... is it non-zero ?

Put in a line like this ...

$obj = olecreateobject ( "serveur001.reverse" )

?"obj=$obj error=@error : @serror"

What is the value of $obj and @error ?

My guess will be that it's ... ummm ... equal to zero !

Shawn.

[This message has been edited by Shawn (edited 24 October 2000).]

I put your line in the script and here is the result :

- under NT 4
obj=0 error=-2147221005 : Chaine de classe non valide.
I think that in english it's : "class string not valid".

- under W98
obj=19009232 error=0 : L'opération s'est terminée.
in english : "operation sucessfully completed".

What is the problem ? Is it my COM object that is not correctly written ?

Nope - nothing wrong with your com component - it's kinda slick actually.

No - it's probably because you haven't registered your com component on your NT workstation .. try this ...

If you haven't done so already - copy the component server .exe or .dll over to your Windows NT workstation and place it in c:\winnt\system32.

Then register it like this ...

regsvr32 mycomponent.dll

or

mycomponent.exe /regserver

You should get a messagebox saying the component was registered.

Then check for a registry key called HKEY_CLASSES_ROOT\SERVEUR001.REVERSE - if it exists - your component was registered.

Then re-run your script ...

My guess this time is ... ummmm ... it'll work perfectly from here on in !

Unless of course - this is a remote com object (DCOM) - in which case you have to go through another process - let me know ...

Shawn.

By the way - it's good to see other's with an interest in writing com objects for kix - whatcah up to ? - anything that may be of interest to "da-board" here ?

Shawn..

[This message has been edited by Shawn (edited 25 October 2000).]

It's my NT workstation which was 'out of order'.
On my second NT workstation, it works well.

I don't understand why on the first workstation the command 'mycomponent.exe /REGSERVER' seems to work, but no keys are added in the registry. !?!
It's the same problem with my DLL (an another component). This way the command 'regsvr32 mycomponent.dll' add the keys in the registry but the script still don't work.

So I think i must scratch my machine and reinstall NT.

Thanks again.

If your component is a DLL, then you only have to worry about installing it using ...

regsvr32 mycomponent.dll

Do you have a .exe version of the same component or is this another component ?

I think what will work is if you have a truely remote (DCOM) component - register it on the server using ...

mycomponent.exe /regserver

Then on your workstation (and I'm talking through my hat now) register the proxy/stub dll using regsvr32 then run a program from start->run called DCOMCNFG.

This utility will allow you to verify (and specify) that the com component is hosted off a remote server (DCOM)...

But like I said - if your just trying to register a DLL on your workstation - regsvr32 should work everytime ... are you getting a messagebox error when you register ? What is it ?

Shawn.

So when you add your dll component to the "out of order" workstation - it registers fine (no errors) but the script still doesn't work ... is $obj still returning a zero in this case ?

Shawn.

Ok, first i have 2 differents components (1 DLL and 1 EXE). They don't do the same thing.

Second, i'm sorry but YES, $Obj == 0. It's a mystery...

And for DCOM, i hope it will be the next step. But i don't have try it yet, and it's not very clear to me now.