serial IO close function from NETCFSDF problem

  • Thread starter Thread starter Markus Humm
  • Start date Start date
M

Markus Humm

Hello,

is it normal, that the close function of OpenNETSDF 1.4 shows a "A
thread <threadID> has ended with return code 0x0." in the output window
of the VS2003 debugger when debugging on a real device?

This happens on at least 3 devices, two of them have WM 5.0 and one has
WM 2003. One of these 5.0 devices makes trouble then. Our app. is closed
but doesn't seem to be finished (not showing under running programs
anymore but not finished either) and can't be started until restarting
the PDA via soft reset.

How do we find out what is causing this? Somebody menationed that a
thread might still be open. But measuring ho much threads are open on
the PPC (at least the one I could measure with process viewer) today
revealed that there were less threads running after closing the than had
before even starting it! When running our app. has 3 to 6 threads,
depending on where one is in the app.

Any hints welcome!

Greetings

Markus
 
Yes this is normal. It simply said that a thread that was running in your
process ended (likely the port monitor thread) and it's telling you the exit
code.

-Chris
 
Yes this is normal. It simply said that a thread that was running in your
process ended (likely the port monitor thread) and it's telling you the exit
code.
Click to expand...

Okay if it's normal, why has the iPaq rx1950 then problems when we close
the serial port but no other model we already tried has?
This porblem is really driving us nuts! Where is our problem or how can
we investigate any further? We don't know how to proceed esp. if we
don't know whats causing this behaviour or how to track it down any further!

Greetings

Markus
 
What's the exact nature of the problem? After you call Close, you're unable
to open it again?

-Chris
 
What's the exact nature of the problem? After you call Close, you're unable
to open it again?
Click to expand...

Hm, sort of. No, it's more complicated:
the close is done when we close our application. That's fine so far. The
app. isn't listed under running apps. anymore and one can start any
other application on the pocket pc, except ours! We can start our app.
again only if we do a soft reset of the pocket pc first.

I don't have the messages/symptoms at hand now, but might get them
tomorrow when in contact with my developper, who also has the pocket pc
to test, again.

One reply always came in groups etc.: there must be something still
running (some thread etc.) which isn't seen in settings / memory /
running programs.

But how to find this and correct this? Don't say process viewer. On
another pocket pc with wm 5.0 I tested it and it had over 150 threads
running (includind system ones). After closing our app. there it had
less running threads as before even starting our app.!

Greetings

Markus
 
Markus,
After closing our app. there it had
less running threads as before even starting our app.!
Click to expand...

But is your app name in the list under Process?

Graham
 
Hi,

We have the same problem with our application on the hp rx1950 with WM 5.0
using
a modified serial port class from OpenNETSDF 1.2. The application still
keeps open
after try to close the last windows (with should close the serial port too).
On WM 2003 there is no problem.
The only idea we have is to upgrade the serial port to the .NET 2.0 class.
Any other solution?

Greetings
Stephan
 
Graham said:
Markus,


But is your app name in the list under Process?
Click to expand...
If you mean settings/memory/running programs: no, otherwise:
On the models I can test right now it is not, but I don't know for the
IPaq rx1950 where it occurs. I can't test it since my developer has it.

Greetings

Markus
 
Stephan said:
Hi,

We have the same problem with our application on the hp rx1950 with WM 5.0
using
a modified serial port class from OpenNETSDF 1.2. The application still
keeps open after try to close the last windows (with should close
the serial port too).
On WM 2003 there is no problem.
The only idea we have is to upgrade the serial port to the .NET 2.0 class.
Any other solution?
Click to expand...

Hm, what did you modify in the class? We're using V1.4 unmodified.
Since we don't need anything other from NETCFSDF or any newer version of
NET CF we don't like that much upgrading. Why installing a huge lib. on
older PDAs only for one class used? Or can one take just the serial
class out of NET CF 2.0 and only deploy this one? We're still using
VS2003 for development which is okay for us. The app. is only some
accessory product for us so investing much in it is not really wanted.

But: good that others experience this bug as well. Before you nearly
nobody answered to my repeated posts about it or if answered only said
general remarks (not iPaq or SDF specific).

Greetings

Markus
 
For all in the U.S: the HP rx1950 is (and only is) in the U.S. the
rx1955. DOn't know the differences but just in case one wondered.

Greetings

Markus
 
Hi,

I don't have any such device to test. However, you can try CFSerialIO from
my homepage. It handles the port close slightly differently than does the
SDF (and the resultant killing of the background read thread).

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004.
See www.hardandsoftware.net for details and contact information.
 
Markus,

No I meant the CE Remote Process Viewer. Your app will not show in runnings
programs if you have closed it, but it may well show up in the remote
process viewer if you left a thread running.

Graham
 
Graham said:
Markus,

No I meant the CE Remote Process Viewer. Your app will not show in runnings
programs if you have closed it, but it may well show up in the remote
process viewer if you left a thread running.
Click to expand...

This is what I replied: on the ones I could test it didn't show in CE
Remote Process Viewer. If you counted the number of threads running in
the whole system before starting and after closing the app. you got the
result that after closing even less threads where running than before
even starting!

Greetings

Markus
 
Dick said:
Hi,

I don't have any such device to test. However, you can try CFSerialIO from
my homepage. It handles the port close slightly differently than does the
SDF (and the resultant killing of the background read thread).
Click to expand...
Hello,

thanks for this tip. I will get my programmer to try this. If he succeds
we'll buy wyour book! ;-)
If not you'll buy a iPaq rx1950/rx1955 ;-) (just kidding)

Greetings

Markus
 
Markus,

Ok, just wanted to be sure. Your problem doesn't appear to be a thread left
running then.

The only reason I was asking is that I'm experiencing a similar problem with
CF2's SerialPort. In my example I can see that the app is still viewable in
the process viewer after the app has exited, in other words I don't believe
that the thread, I create to run my GPSReceiver class is shutting down when
the power comes on again.

In normal operation it works correctly - but what I'm trying to do is trap
a "power off/power on" event, and restart my GPS, if the user hits the power
button and powers off and then on again. Its after I get the PowerOnEvent
that I don't seem to be able to kill my receiverThread.

If you are considering moving the app to VS2005, I would think you would be
ok with CF2's SerialPort, unless you are attempting what I'm trying to do.
The only problem I've had with SerialPort is that it was unreliable in
SerialPort.Close until I added a SerialPort.ReadTimeout = 0, before the
SerialPort.Close(). I can't say I understand why that fixed it, but I found
it was required.

For your info my test devices are hx4700 and h5450. ie 2003SE and 2003. No
WM5 devices, still waiting on HP for the 4700 upgrade.

Graham
 
Dick said:
Hi,

I don't have any such device to test. However, you can try CFSerialIO from
my homepage. It handles the port close slightly differently than does the
SDF (and the resultant killing of the background read thread).
Click to expand...
Hello,

seems you have to buy one ;-)
We tried your library now and the close works well as expected, but:
we only receive 7 Bit per Databytes as it seems. My programer says he
sets the communication parameters to 8 bits with 1 stopbit. Sending
seems to work, otherwise our external device wouldn't send us the
acknowledge packets, but receiving is olny 7 bits per byte.

How can that be? And how to change? If we get it to work (maybe with
your help?) we'll buy your book instantly, but not before it works for
us! (except you can prove us that we need the source for a change and
tell us what the change is. I hope you can solve this...

Greetings

Markus
 
Hi,

Are you using the InputArray method? InputString only returns ASCII text
data (thus, 7-bits). InputArray works fine for me.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004.
See www.hardandsoftware.net for details and contact information.
 
Dick said:
Hi,

Are you using the InputArray method? InputString only returns ASCII text
data (thus, 7-bits). InputArray works fine for me.
Click to expand...

Hello,

yes my programmer uses that method now he found it. That works somehow
but according to him not reliably.

He sends a datapacket to our device, waits for 25 or 50 ms and the
querys the buffer for incomming answers. Often enough there is none but
when querying a second time he gets two responses because he already
sent the next request out and got the responses to both at the same
time. (which can't be with our hardware)

Now he tries to use the event driven stuff, but has some problems to
understand it, because he has no documentation (but will order your book
now - so be prepared for an order! ;-) ). He didn't find one required
property or so that must be set for event driven operation.

Polling like he did did work for the OpenNETCFSDF but not for your
components as it seems.

Another thing: what for is that timeout property or method?

Any further hints?

Greetings

Markus
 
Back
Top