Re: WaitForSingleObject returns immediately



Actually it's not just what the OS does, but also the app itself. The apps themselves on WM are single-instancing themselves. So you'll have the same problem on "regular" Windows CE if the apps you use single-instance themselves.

OP is probably correct that his tool is probably not useful for apps designed to be single-instancing. There is a different approach to take, though, if you want to know when an app terminates. Well, I should say a different way to get a process handle. Rather than using the one returned from CreateProcess, you could wait a second or so after the call to CreateProcess (to give app time to "open"). Then hunt down its main window with FindWindow and use GetWindowThreadProcessId followed by OpenProcess. That has its own associated problems (e.g. how long to wait and knowing the class and/or caption of the window), but would work.

--
Michael Salamone, eMVP
Entrek Software, Inc.
www.entrek.com


"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT com> wrote in message news:u7H3o4mcIHA.1960@xxxxxxxxxxxxxxxxxxxxxxx
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.
>> >> >> >
>> >> >> >
>> >> >> >
>> >>
>> >>
>> >>
>>
>>
>>






.