Board index » delphi » createprocess ?

createprocess ?

I'm a relative newcomer to Delphi. I'm running D4 (std).

I saw this recently in some source code..
Can anyone explain to me , preferably line by line and in plain english,
what does code does please?

function TForm.RunAndWait(const filename:String):DWORD;
var
   StartupInfo:TStartupInfo;
   ProcessInfo:TProcessInformation;
begin
Result:=STILL_ACTIVE;
GetStartupInfo(StartupInfo);
   if CreateProcess(nil,PChar(filename),nil,nil,IsConsole,
       NORMAL_PRIORITY_CLASS,nil,nil,StartupInfo,ProcessInfo)
    then try
         if WaitForSingleObject(ProcessInfo.hProcess,INFINITE)=WAIT_OBJECT_0
           then GetExitCodeProcess(ProcessInfo.hProcess,Result);
         finally
           CloseHandle(ProcessInfo.hThread);
           CloseHandle(ProcessInfo.hProcess);
         end;

end;

t.i.a.
Rob O.T.

 

Re:createprocess ?


"Garry Charles" <grc-the-mas...@brain-cpu.freeserve.co.uk> skrev i melding
news:_G5T6.58395$8Z5.1821007@monolith.news.easynet.net...
Quote
> I'm a relative newcomer to Delphi. I'm running D4 (std).

> I saw this recently in some source code..
> Can anyone explain to me , preferably line by line and in plain english,
> what does code does please?

> function TForm.RunAndWait(const filename:String):DWORD;
> var
>    StartupInfo:TStartupInfo;
>    ProcessInfo:TProcessInformation;
> begin
> Result:=STILL_ACTIVE;
> GetStartupInfo(StartupInfo);
>    if CreateProcess(nil,PChar(filename),nil,nil,IsConsole,
>        NORMAL_PRIORITY_CLASS,nil,nil,StartupInfo,ProcessInfo)
>     then try
>          if

WaitForSingleObject(ProcessInfo.hProcess,INFINITE)=WAIT_OBJECT_0

Quote
>            then GetExitCodeProcess(ProcessInfo.hProcess,Result);
>          finally
>            CloseHandle(ProcessInfo.hThread);
>            CloseHandle(ProcessInfo.hProcess);
>          end;

> end;

It starts an application specified by the 'filename' parameter
("CreateProcess...") , and stops at the line

  "WaitForSingleObject..."

until the launched application is closed.

Then, the exit code or Windows error code (or a success code) is returned by
the "GetExitCodeProcess..." (very unlikely this one won't be called, as
INFINITE timeout is specified)

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorgeremovet...@itte.no (remove the obvious)

Re:createprocess ?


[snip your comment]

Quote
> It starts an application specified by the 'filename' parameter
> ("CreateProcess...") , and stops at the line

>   "WaitForSingleObject..."

> until the launched application is closed.

[end snip]

I am assuming then that this is similar to a "shell" type of execution ?

One question though, if this routine "executes and waits until closed"
would this necessarily mean that it would take control, take focus away from
the other applications running during the process ?

Rob O.T.

Re:createprocess ?


"Garry Charles" <grc-the-mas...@brain-cpu.freeserve.co.uk> skrev i melding
news:yWkT6.61937$8Z5.1906533@monolith.news.easynet.net...

Quote

> [snip your comment]
> > It starts an application specified by the 'filename' parameter
> > ("CreateProcess...") , and stops at the line

> >   "WaitForSingleObject..."

> > until the launched application is closed.
> [end snip]

> I am assuming then that this is similar to a "shell" type of execution ?

Yes, the main difference is what it returns. ShellExecute returns a
hInstance, while CreateProcess returns a hProcess/hThread.

Quote
> One question though, if this routine "executes and waits until closed"
> would this necessarily mean that it would take control, take focus away
from
> the other applications running during the process ?

It would "take control", as the calling application freezes until the
launched app is finished. It won't refresh it's windows, for one.
AFAIR, focus is not changed.

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorgeremovet...@itte.no (remove the obvious)

Re:createprocess ?


[snip your reply]

Quote
> Yes, the main difference is what it returns. ShellExecute returns a
> hInstance, while CreateProcess returns a hProcess/hThread.

[end snip]
Careful friend, I'm right on the line now between understanding and
nothingness...
hProcess being a pointer or reference to the called application ?
Is this what a 'handle' is?

[snip your reply]

Quote
> > One question though, if this routine "executes and waits until closed"
> > would this necessarily mean that it would take control, take focus away
> from
> > the other applications running during the process ?

> It would "take control", as the calling application freezes until the
> launched app is finished. It won't refresh it's windows, for one.
> AFAIR, focus is not changed.

[end snip]

For example then, if this routine was used by a calling application to call
a sub-application or another program (by its name)...on the basis that it
freezes
(temporarily) the calling application, surely wouldn't this be a problem for
the calling program or other that are running at the time?

Imagine if a someone was running msWord on a computer, vigorously tapping
away at the keys. Hypothetically, that same computer could have a program
running on it which runs the routine (previously mentionend) on a timer
control. That other program would then interrupt  msWord, thus that would
probably cause the msWord document to lose keyboard input at the moment(s)
that the above routine kicked in?

How could software cope with the interruptions, would a cure be the use of
Application.Processmessages ?

 on the same computer

? Wouldn't it
be better to have some way of maintaining the calling application's

Re:createprocess ?


"Garry Charles" <grc-the-mas...@brain-cpu.freeserve.co.uk> skrev i melding
news:skpT6.4$Sd.3084@monolith.news.easynet.net...

Quote
> [snip your reply]

> > Yes, the main difference is what it returns. ShellExecute returns a
> > hInstance, while CreateProcess returns a hProcess/hThread.
> [end snip]
> Careful friend, I'm right on the line now between understanding and
> nothingness...
> hProcess being a pointer or reference to the called application ?
> Is this what a 'handle' is?

A handle is an ID that identifies various object types in Windows. What
decides what kind of handle you get, is what routine you call and what this
returns. What you actually *need* may be another question, this is usually
determined by the next thing you're gonna do ;-) In the example with the
CreateProcess call, you need to use it because WaitForSingleObject won't work
with a hInstance value (returned by ShellExecute), AFAIK.

Quote
> [snip your reply]
> > > One question though, if this routine "executes and waits until closed"
> > > would this necessarily mean that it would take control, take focus away
> > from
> > > the other applications running during the process ?

> > It would "take control", as the calling application freezes until the
> > launched app is finished. It won't refresh it's windows, for one.
> > AFAIR, focus is not changed.

> [end snip]

> For example then, if this routine was used by a calling application to call
> a sub-application or another program (by its name)...on the basis that it
> freezes
> (temporarily) the calling application, surely wouldn't this be a problem
for
> the calling program or other that are running at the time?

Yes, but this code is intended to behave like this...it may actually be cases
where you *need* to wait until the external app is finished. If you don't
need to wait, just use CreateProcess or ShellExecute and continue....

Quote
> Imagine if a someone was running msWord on a computer, vigorously tapping
> away at the keys. Hypothetically, that same computer could have a program
> running on it which runs the routine (previously mentionend) on a timer
> control. That other program would then interrupt  msWord, thus that would
> probably cause the msWord document to lose keyboard input at the moment(s)
> that the above routine kicked in?

> How could software cope with the interruptions, would a cure be the use of
> Application.Processmessages ?

The point is, with this code *nothing* is executed while waiting. There may
be other approaches, like polling at intervals, etc., or running the code in
an own thread.

--
Bjoerge Saether
Consultant / Developer
http://www.itte.no
Asker, Norway
bjorgeremovet...@itte.no (remove the obvious)

Re:createprocess ?


Quote
"Garry Charles" <grc-the-mas...@brain-cpu.freeserve.co.uk> wrote in message

news:skpT6.4

Quote
> For example then, if this routine was used by a calling application to
call
> a sub-application or another program (by its name)...on the basis that it
> freezes
> (temporarily) the calling application, surely wouldn't this be a problem
for
> the calling program or other that are running at the time?

> Imagine if a someone was running msWord on a computer, vigorously tapping
> away at the keys. Hypothetically, that same computer could have a program
> running on it which runs the routine (previously mentionend) on a timer
> control. That other program would then interrupt  msWord, thus that would
> probably cause the msWord document to lose keyboard input at the moment(s)
> that the above routine kicked in?

When the "calling thread" uses WaitForSingleObject it is blocked, i.e. it
waits, on the specified event. When that event occurs execution continue in
the caller. All of this is entirely independant of what other threads are
doing on the machine. Win95/NT use pre-emptive multi-tasking which means
that each task will get its share of time, regardless of the actions of
other threads (at least theoretically). So, if I understand the above
paragraph, no the other program wouldn't affect msWord or the characters it
is receiving from the keyboard. Naturally its entirely possible for the
"calling thread" to programmatically take the keyboard focus away from
msWord following the WaitForSingleObject, but this action isn't as a direct
result of it being woken up.

Quote

> How could software cope with the interruptions, would a cure be the use of
> Application.Processmessages ?

Application.ProcessMessages only has effect in the calling process. It
simply forces the application to processes all messages in its message
queue.

When an application uses WaitForSingleObject it appears unresponsive to user
input because the o/s has blocked it until the waited for event occurs.
There are two solutions that come to mind. The first is to have the
CreateProcess and WaitForSingleObject in their own thread so that the main
thread can continue processing user input. The second is to spin on a
shorter timed WaitForSingleObject and Application.ProcessMessages, e.g.

totalWait := 0;
repeat
    wResult := WaitForSingleObject (processInfo.hProcess, 300);
    Application.ProcessMessages;
    inc (totalWait, 300);
until (wResult <> Wait_TimeOut) or (totalWait > someMaxWait);

In both cases one has to be careful while waiting that permitted ui actions
are not dependant on the results that are being waited on.

Other Threads