I have an external encryption routine written in c#, which I can call from within open insight to write an encrypted string to a file, using the syntax

call utility('RUNWIN','encrpytionroutine.exe plainstring encryptionkey outputfile', -7)

then to retrieve the encrypted string I can use:

osread encryptedstring from outputfile else encryptedstring='

When I run this from a normal application it works fine, however I would like it to pass an encrpyted string back to a web service.

I've tried running it through oecgi and it appears that the executable never gets called. I don't get an error message it just fails to call the executable.

My basic question is this, is this something simple like permissions on the executable which need setting or is it a fundamental issue with running executables via oecgi?

From OECGI use Shellexecute

Something like:

declare function shellexecute

handle=0

proc=encrpytionroutine.exe'

params=plainstring encryptionkey outputfile'

folder=drive()

mode= -7

ret=shellexecute(handle, proc:\00\,params:\00\,folder:\00\, mode)

Someone with my initials prototyped Shellexecute incorrectly, which is why you need to append the \00\

That works perfectly, apart from one small problem.

The encryption bit of my program now looks roughly like this

oswrite encryptThis to tempPath

debug handle=0 operation=' proc =encrpytionroutine.exe' params="':tempPath:'" "':tempPath:'" ':encryptPasswd:' HEX' folder=drive() mode =1 ret=shellexecute(handle,operation:\00\,proc:\00\,params:\00\,folder:\00\,mode) For larger text files I write them away onto the hard disk before reading them in from my encryption program. However when I run this code, the file doesn't get written before shellexecute is called, and the encryption routine returns a file not found error. To make things weirder, if I uncomment the debug and step through the program the file gets written and everything works as expected. Is this a known issue, is there any way to get round it? </QUOTE> —- === At 04 AUG 2010 10:49AM Bob Carten wrote: === <QUOTE> ShellExecute launches a separate thread. That is why you are seeing timing issues. Stepping through with the debugger gives the other thread time to complete. There was a Works thread about createprocess and alternatives a few years ago. That thread discusses some roll your own code, a tool from SRPCS, and a freeware tool. I've also had good lick using the WSH shell with the EXEC method. Finally, If you have written the C# exe yourself, try making it a COM-exposed dll instead, then you can call it using OLECREATEINSTANCE and OLECALLMETHOD and forget about temp files and timing issues. - Bob </QUOTE> —- === At 10 AUG 2010 04:01AM Jon Brewster wrote: === <QUOTE>I worked out it was timing issues, I was exasperating the problem by tidying up after myself too keenly. Anyway, I went down the COM exposed dll route in the end. Thanks for all your help. Jon </QUOTE> View this thread on the forum...