seems that running programs window couldn't kill my application

[Guest]

Hi all

i have this strange problem: i have developped a c# application that runs
fine but when i go to settings>System>memory>running programs> and i kill my
application here something strange happens:

the application ends, its name disappers from the list, but if i use the
remote process viewer i can see how it is still running...only difference
before the fake ending in the Window column of process viewer i read
FAKEIMEUI, after the closing i have no entry...

if i kill the application with process viewer always OK

any ideas? thanks...

if it is useful i can sy that i use some unmanaged code, for istance i use a
waitforsingle object, some createvent etc..even if i don't think this is the
problem

 

[Paul G. Tobey [eMVP]]

All the Running Processes window is trying to do is close your top level
window. *You* have to make sure to exit all threads that you have running
and make sure that the main event loop exits. Remote Process Viewer will
call Terminate Process to really, really kill you, so it's not doing the
same thing and you should *not* require TerminateProcess, if your
application is written correctly.

Paul T.

 

[Guest]

yes it is coorect that it will not good to call terminate process...
but i have the same problem even if i close my main form with the stylus
tap: i have not the minimize icon but the close one..

but how can i make sure that all my thread are exited?

i have the main thread wich run the programs and a thred which a start a
while(true) loop to monitor the set of an event by waitforsingleEvent... i
have the doubt that this thread doesn't exit when i close the program ..how
can i solve thi s problem?

 

[Paul G. Tobey [eMVP]]

By designing the thread code so that you have some means of telling them to
exit. It should be obvious that "while (true)" isn't going to be exitable!
Since you're waiting on an event, I'd create a global variable which
indicates to the thread whether it's time to exit or not.

protected bool timeToExit = false;

ThreadProc()
{
while ( !timeToExit )
{
DWORD waitResult = WaitForSingleObject( event, <timeout?> );
if ( waitResult == WAIT_FAILED )
break;

if ( waitResult != WAIT_TIMEOUT )
{
// Do something
}
}
}

// Somewhere in your main code when it's time to exit the thread.
timeToExit = true;
SetEvent( event );

// You might also wait for the thread to exit before exiting the main
program by
// waiting on the thread handle, if you want.

Paul T.

 

[Guest]

thanks a lot ... i thought that even if the will true is not exitable the CLR
takes care to destroy all thread that was called by the main form..

only the last question ..why after you change to false the global variable
you set the event? i have tried the suggest of the global variable and it
semms to run even if the call to set..

 

[Paul G. Tobey [eMVP]]

What if what you want is to run the application in the background after the
main form is closed?

I don't quite understand the question. If you're asking, why did you set
the event, as well as the flag, because I don't know *anything* about what
your WaitForSingleObject() call is passed. Maybe the time out is 10 seconds
or maybe INFINITE! You should really also check the flag after
WaitForSingleObject returns to see if timeToExit is true, since you want to
get the hell out of the thread as soon as possible.

Paul T.

 

[Guest]

ohh.. i'am a great donkey..eh eh i have understood the reason of the set
event, if i don't call it i have to wait for the next timeout before the
thread exits..thanks

 

[Guest]

The CLR doesn't destroy them becasue eitehr (A) you're running in CF 1.0 and
don't have IsBackground available for the thread or (B) you're running CF
2.0 and haven't set IsBackround to true for the worker thread. The CLR has
no idea that you want to stop all threads when one exits.


--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com

 

[Guest]

the strange thing is that i have set the worker thread as background thread
thread a = new Thread();
a.isBackground = true;

for this reason it seems quite strange that it doesn't exit after the main
form is killed..perhaps is the presence of the while(true) which makes the
clr confused..

 

[Paul G. Tobey [eMVP]]

You don't *want* it to exit randomly! That would be a horrible way to have
things work. How would you close files, network connections, or free
unmanaged resources allocated by your thread if it exited at some random
point. You *want* it to exit when you tell it to and never before or after
that.

Paul T.

 

[Guest]

scuse me but i don't understand your answer...if i close the main window i
want to exit ..so it seems strange taht if i set my thread as background it
doesn't exit but probably i'm missing something..

 

[Guest]

Is the thread making a system call? If it's in some wait, then it's still
not going to exit, even if it's a background thread.

Setting a thread's IsBackground to true is a good practice, but it doesn't
take care of all scenarios.


--
Chris Tacke - Embedded MVP
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com

 

[Paul G. Tobey [eMVP]]

My examples in the last message should give you some thoughts, particularly
in the case of unmanaged resources which are *NOT RECLAIMED* automatically,
thus would be leaked if the thread was just somehow randomly dropped. The
framework could implement a design pattern for background threads that could
do the right thing, but all-in-all, I'd much rather have real control over
what happens when, so I can be reasonably sure that my code doesn't damage
the system. The little IsBackground examples in the help are really just
silly, since they do no useful work. If you want to generate messages
periodically, by all means just let the thread be exited, but I seldom feel
the need to build threads for those kinds of things.

Paul T.

 

[Guest]

mmm probably the thread doesn't exit because i call some unmanaged API inside
it
....i think i have solve my problem with the global variable tath stops my
while(true)...