Thanks Doug!
That stopped the .Net Framework from shutting down the application and
the application keeps working as it should - I can run the scenario
over and over again and it keeps working.
It is quite difficult to detect that the COM port has disappeared.
That means I have to check if the COM port exists every time I want to
access it/every time when I want to read or write something.
Unfortunately there is nothing in the SerialPort class that can tell
if the port has been disposed except you can subscribe to an "port
disposed event" or I can use SerialPort.GetPortNames() and check if
the port is still in the list. But none of these things will really
solve the problem - the port could have been removed right after I had
done the check and was going to write to the port.
Best regards,
Kim Therkelsen
On 8 Feb., 20:57, "Doug Forster"
<doug_ZAPTHIS_AT_ZAPTHIS_TONIQ_DOT_CO_DOT_NZwrot e:
HiKim,
Therefore I have a try-catch around this
section but it is unable to catch the objectDisposedException which I
believe i generated internally in the .Net Framework and not caught
where it should have been caught.
I suspect you may be correct about this. There is an unfortunate change of
behaviour in the 2.0 framework which kills the app if a thread has an
unhandled exception instead of just quietly killing the thread. This is all
very fine in theory if it is *your* code but if it is a third party
component or perhaps even the framework itself then life gets very
difficult. You can get around this behaviour with an app config file
containing this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled="true" />
</runtime>
</configuration>
Save it in the same directory as your app and call it something like
myApp.exe.config.
This *is* a kludge - there is no guarantee that the component code will
behave correctly in this situation but its worth a try. If it does work you
will then need to find some way of detecting that the event has happened.
Good luck.
Cheers
Doug Forster
