I am using a System.Diagnostics.Process object to start a separate prowin32.exe session from my OpenEdge aplication. This works fine, and I can monitor and/or stop the process using the attributes and methods of the Process object.
I want to use the same method for starting and optionally aborting a batch mode process. When I switch to "mbpro" instead of "prowin32" for the Process, two processes are actually being started: a cmd.exe (for the mbpro.bat script) and second child process for _progres.exe. If I attempt to stop the process using the Process.Kill() method, it only stops the top-level process (cmd.exe).
Does anyone know a way of finding child processes for a given Process object that would alllow me to also kill the child processes? A "Kill Tree" of sorts for a given Process object.
Thanks for any advice / ideas.
Instead of using the mbpro batch script, I'd start _progres with the parameter -b. That parameter is responsible for the batch mode and mbpro does nothing else (except setting environment vars etc).
Please post some code samples if it works :-)
Don't you wish you had a multi-threaded client?
http://www.oehive.org/MultiThread
I tried that initially, but was getting a "unable to understand argument" when the _progress session started. It's very possible it was the command line-- I haven't investigated it yet.
I am temporarily side-tracked at the moment, but I will try and update / post some code samples at some point soon.
Indeed, "long process" this is the very reason I am creating the System.Diagnostics.Process object... Your paper looks very good. We can only hope that Progress will someday provide threading.
This works quite nicely for me:
def var cUrl as char.
def var oProcess as System.Diagnostics.Process.cUrl = "C:\Devarea\dlc\oe102b\bin\_progres.exe".
oProcess = System.Diagnostics.Process:Start(cUrl, " -b -p custom3.p ").MESSAGE
oProcess:Id
VIEW-AS ALERT-BOX.
custom3.p just contains a message output to a file (for verification's sake).
-- peter
Hoping is likely to keep you waiting a long time. Make noise. Post on these forums about your use case. Talk to your sales rep. Button-hole people at Exchange ... although that is hard to do with an on-line Exchange. Identify relevant people and send them e-mails. This is why I wrote this use case in the first place, for presentation to a group of PSC staff with whom I was meeting at Exchange.