I think I would have a single onComChange event call back fun() and pass "connected" or "disconnected" as the 1st parameter. A 2nd parameter which includes "unknown" can be expanded on later...
Am I missing something from the concepts: It could simply have one parameter with 3 states: Connected/Disconnected/Unknown. Do you mean something special by
later?
As far as I have observed and read, when something is plugged in or out, message DBT_DEVNODES_CHANGED is sent multiple times. After a while a BT_DEVICEARRIVAL or DBT_DEVICEREMOVECOMPLETE is sent. If both BT_DEVICEARRIVAL and DBT_DEVICEREMOVECOMPLETE are received, two events are generated, possibly device(s) were unplugged, while another one(s) were plugged in.
Then actions shall be taken.
TSerialWatcher generates OnConnected and OnDisconnected.
TSerialSelector uses both of them to start refreshing.
But
TLazSerial generates only an
OnDisconnected event when the activated serial port is unplugged.
So having one event with parameters does not seem a better solution to me.
FYI mode: Depending on the PC dongle driver, I sometimes get some strange connect cycling with BT devices going in and out of range. I think the driver was trying to say "reconnected" but my end was too simple to handle this new notification. I ended up closing the port and reopening it anyway (which worked). But this "new connect" trigged my code to re-download device mode setting so I would ended with more Comm traffic at a time when the connection was at it's weakest.
Mas
This is a good reminder, I have not tested (much) the behaviour with BT devices.
Windows assigns port names (two per dongle) (or they are rather assigned manually) when a dongle is connected, but it does not remove them when it is unplugged, so maybe it is not possible to detect if the dongle is available. And losing and restoring range shall be even trickier.
I have no idea how Linux handles these cases.
I intend to investigate these.