Re: WaitForSingleObject returns immediately
- From: "Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com>
- Date: Mon, 18 Feb 2008 13:38:00 -0700
On Windows Mobile, it won't work with virtually any application, no. On
ordinary Windows CE, it will work with virtually everything (just the
opposite).
Paul T.
"Fabio" <Fabio@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E8F8D48A-A47A-4DA9-8550-2E3FE1361942@xxxxxxxxxxxxxxxx
Nevermind, I've decided to stop trying to work around it and simply accept
the way it works. It won't work with applications that were not intended
to
be terminated.
Thanks a ton for the help!
Fabio.
"Paul G. Tobey [eMVP]" wrote:
But this is an application launcher of some sort or a "batch file"
processor
or what? I don't see any value in what you're doing, so far, so the big
picture still isn't clear to me. If your application has no UI, you can
just do this in the main() code for the program and no one will be the
wiser
because you have no message loop to block with calls to
WaitForSingleObject(). If your application *does* have UI, you *must*
continue to service your message loop while the other application runs.
Why
would the 'user' call you to do this simple operation? Still need a
higher-level view...
Paul T.
"Fabio" <Fabio@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:B80E6042-62EC-4EDE-8506-81650FA58704@xxxxxxxxxxxxxxxx
My application should be able to receive a command line and launch the
application with the parameters specified on the command line.
The user may choose to wait until the launched application terminates
to
continue or not. If he chooses to wait, my application returns the
launched
application exit code.
So if the user decides to run a batch of applications sequentially, I
have
to wait until one is over to run the next.
Fabio.
"Paul G. Tobey [eMVP]" wrote:
Well, you wouldn't want the main thread of your application to use
this
scheme anyway. Doing a WaitForSingleObject() in the UI thread is
*always* a
bad idea, whether on the desktop or on a device. At the very least,
you
should do that in a separate thread that is started in response to
whatever
UI event is supposed to trigger the process start, or do the process
creation in the UI thread, but do *not* block in
WaitForSingleObject(),
maybe using a timer or something to periodically check whether the
application has exited or not.
No, that would be contrary to the system design for Windows Mobile.
You
would *absolutely not* want to terminate random processes, either,
even
if
you found a way to detect Smart Minimize from your process.
Take a step back and tell us *what* you're trying to do. We know how
you're
trying to do it, but we have no clear idea (or at least I don't), what
this
is all in service of. That is, why do you care when the application
exits?
Or if it exits? Or when it exits?
Paul T.
"Fabio" <Fabio@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:8CCA4E18-4E24-4840-915C-01D37440ABF8@xxxxxxxxxxxxxxxx
Oh, that explains it. Didn't know that using WM make any difference
in
this
case.
The worst part is that I can't use the switcher bar while my
application
is
blocked, resulting in a deadlock unless the launched application has
a
specific option to terminate it.
Is there a way to launch an application with some sort of "disable
start
minimize" flag or monitor the application messages to terminate the
process
when it is suspended for this Smart Minimize?
Fabio.
"Paul G. Tobey [eMVP]" wrote:
Wait a minute! This is Windows CE or Windows Mobile? If WM,
that's
100%
explained (and there's nothing you can do about it that I can think
of).
If
it's Windows CE, it should work correctly. In Windows Mobile, to
improve
responsiveness, Microsoft set things up so that the X button does
not
close
the application. It's called Smart Minimize and you can look up
the
details
in the newsgroup archives and all over the place. When you do
that,
launching the program from the Start menu is, of course, much
faster,
since
you're not launching anything, really.
Paul T.
"Fabio" <Fabio@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5A5D8D25-0970-4030-8EBD-43DACC0B53AF@xxxxxxxxxxxxxxxx
I think I found out why it is working that way.
I used ToolHelp functions to check the process list and noticed
there
were
closed programs on the list. I activated the Switcher Bar on the
PDA,
closed
all programs and started my application in debug.
So here's what really happens when I run my application:
The first time my application tries to launch another
application,
it
gets
blocked indefinetely because hitting 'X' does not terminate the
process.
If I force my application to stop and run it again, it "calls"
back
the
same
process it launched the last time instead of launching a new one,
but
this
time WaitForSingleObject returns immediately.
I still don't know how to make it work the way I want though.
Fabio.
"Fabio" wrote:
Oh sorry, I should have explained that. Here's its definition:
void *startInfo = NULL;
#if !defined WINCE
STARTUPINFO si;
memset(&si, 0, sizeof(si));
startInfo = &si;
#endif
I don't like to spread #ifdef statements inside the functions
and
this
way
the rest of the function is pretty much the same for both WIN32
and
WINCE.
Anyway, using NULL instead of startInfo doesn't solve the
problem.
Right now I'm using a device with Windows CE .NET and evc4, but
my
goal
is
to make the application compatible with Windows CE 3.0 and
above.
Fabio.
"Paul G. Tobey [eMVP]" wrote:
Not sure, but startInfo is not supported, according to the
help I
have.
What's that set to? What version of Windows CE are we talking
about?
Paul T.
"Fabio" <Fabio@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:0C785499-92D4-472B-9C4A-EAFDEF8E7EB2@xxxxxxxxxxxxxxxx
Hi.
I'm making an application that needs to launch an external
application and
wait until it is closed to continue. Here's is the code:
if (!(ret = !CreateProcess(szCommand, szArgs, null, null,
false,
0,
null,
null, startInfo, &processInfo)))
{
WaitForSingleObject(processInfo.hProcess, INFINITE);
GetExitCodeProcess(processInfo.hProcess, &ret);
}
CloseHandle(processInfo.hThread);
CloseHandle(processInfo.hProcess);
}
It works in WIN32 with any application and works in WINCE
when
the
application launched is the HelloWorld example created by
evc4
using
the
new
project wizard. However, it does not work in WINCE when I
call
other
applications, like iexplore, notes, pword, fexplore, etc...
Instead of waiting, the function returns immediately the
value
WAIT_OBJECT_0
and GetExitCodeProcess fills the ret variable with 0, even
though
the
process
is still running.
What should I do to make it work as expected?
Thanks in advance.
.
- Follow-Ups:
- Re: WaitForSingleObject returns immediately
- From: Michael Salamone
- Re: WaitForSingleObject returns immediately
- References:
- Re: WaitForSingleObject returns immediately
- From: Paul G. Tobey [eMVP]
- Re: WaitForSingleObject returns immediately
- From: Fabio
- Re: WaitForSingleObject returns immediately
- From: Fabio
- Re: WaitForSingleObject returns immediately
- From: Paul G. Tobey [eMVP]
- Re: WaitForSingleObject returns immediately
- From: Fabio
- Re: WaitForSingleObject returns immediately
- From: Paul G. Tobey [eMVP]
- Re: WaitForSingleObject returns immediately
- From: Fabio
- Re: WaitForSingleObject returns immediately
- From: Paul G. Tobey [eMVP]
- Re: WaitForSingleObject returns immediately
- From: Fabio
- Re: WaitForSingleObject returns immediately
- Prev by Date: Re: WaitForSingleObject returns immediately
- Next by Date: Re: Accepting socket connections
- Previous by thread: Re: WaitForSingleObject returns immediately
- Next by thread: Re: WaitForSingleObject returns immediately
- Index(es):