can not delete excutable in Pocket PC

Khanh · May 11, 2004

hi all,

We are developing an pocket pc application for months, and we often
see a weird bug: since deploying informs to be failed, we try to
delete the executable but we can not delete it in pocket pc sometimes,
then we have to reset device!!! This event often happen when we stop
debugging in VS.NET 1.1 2003, and occur both in device and emulator.
Any advice would be very appreciated.

FYI: developing machine: P4, WinXP
pocket pc: Fujitsu Pocket LOOX Wireless
Model（FLX3AW）

Normally, we do the exact steps : rebuild, connect, deploy and
debug.

Many thanks,
Khanh

Peter Foot [MVP] · May 11, 2004

Your application is still running, either you have minimized the window in
which case it will be invisible but still running in the background (in
which case you should be able to terminate it from Settings > Memory >
Running Programs). Or you may have created background threads in your
application which continue to execute when your forms have been closed.

Peter

Guest · May 12, 2004

Peter Foot in his reply noted that a common problem with CF is to close the form with threads still running. I have the same problem and I'm looking for a suitable 'generic' way of dealing with this issue as the CF does not seem to allow you to kill these threads unconditionally
For a progress form I use, I pass a form level variable which the forms codes watches on each loop. So it terminates quite nicely when required
For async web service queries and also serial IO (OPENNETCF.io.serial) I don't have an effective termination techniqu
I need to
1. Know which threads are active. In some cases I do know thi
2. Have a communication method to tell them to die quetly. This is the hard par
3. Wait until this death occur

In the good old days, a "death in the family" would bring down the curtains. This one is a real pain

Any suggestions on top of my rather simple "form" solution appreciate

BTW, I get rid of the program using PS and Kill on my WInCE device at the command prompt. This may not be applicable on PPC

Rob von Nesselrod
..NETCF Nobod
Cairns, Australia

Paul G. Tobey [eMVP] · May 12, 2004

For serial I/O, as we've discussed in this group previously, you can close
the port handle from the 'main' thread, causing the ReadFile() or
WriteFile() operation under way on the port to complete with an error.

Since you have to start all of your threads, it seems like you should know
about them. You can use an event as a signal to exit a thread and have that
thread wait on or check periodically the status of the event (it could check
when it gets an error back from ReadFile or WriteFile, for example). When
the event is set, exit the thread cleanly. For waiting for that signal to
take effect and the thread to exit, the main thread can use
WaitForSingleObject, for one thread, or WaitForMultipleObjects, for several
threads, waiting in each case on the thread handle returned from
CreateThread (these are all P/Invoke names, of course).

Paul T.

robvon said:
Peter Foot in his reply noted that a common problem with CF is to close

the form with threads still running. I have the same problem and I'm looking
for a suitable 'generic' way of dealing with this issue as the CF does not
seem to allow you to kill these threads unconditionally.

For a progress form I use, I pass a form level variable which the forms

codes watches on each loop. So it terminates quite nicely when required.

For async web service queries and also serial IO (OPENNETCF.io.serial) I

don't have an effective termination technique

I need to:
1. Know which threads are active. In some cases I do know this
2. Have a communication method to tell them to die quetly. This is the hard part
3. Wait until this death occurs

In the good old days, a "death in the family" would bring down the

curtains. This one is a real pain.

Any suggestions on top of my rather simple "form" solution appreciated

BTW, I get rid of the program using PS and Kill on my WInCE device at the

command prompt. This may not be applicable on PPC.

Guest · May 12, 2004

Paul

Thanks for the quick reply
I do close the serial ports as follows, in my form_closing event
I've also got the ubiquitous global exception handler in sub main which hides the damage - well I presume so as things do go quietly
For Each dcb In dcbComm
If Not dcb.serialport Is Nothing The
If dcb.serialport.IsOpen Then dcb.serialport.Close(
End I
Nex
Now all I have to do is figure out what other thread is keeping the app awake. I think there may be some tools around to help with this so I will go and do some RTFM

Chris Tacke, eMVP · May 12, 2004

Killing a thread through an explicit terminate call is a bad idea in any
language, so the omission of a method in the CF isn't really a bad thing.
Threads should always be allowed to run to completion and it is up to the
developer to create a mechanism, whether it's through a global flag , an
event or whatever, to allow them to die properly.

The ThreadEx class form OpenNETCF *does* implement ThreadEx.Terminate, but
because it's a bad idea, calling it always throw an exception (it still
terminates the thread though).

--
Chris Tacke, eMVP
Co-Founder and Advisory Board Member
www.OpenNETCF.org
---
Windows CE Product Manager
Applied Data Systems
www.applieddata.net