FreeEMS Issues - Tunix
View Issue Details
0000562TunixGeneral Featurespublic2012-04-05 10:562012-04-07 12:37
all of them
0000562: Determine Best Serial Port Behavioural Semantics
I can't remember how this behaves, as I started explicitly telling it what to do, and it honours that, but this has pissed me off on numerous occasions. I need to investigate what it does and consider what it should do.
No tags attached.
png mtx.badly.behaved.serial.port.scan.png (20,406) 2012-04-06 22:27

2012-04-06 22:22   
This is trickier to trigger under the current regime as MTX doesn't test the port unless it tries to send a packet and there is no polling service right now (will be again sooner or later) so you have to make it send a packet before it figures out that the device has gone.

When you do, though, you get this: [^]

Which I'll attach momentarily. The trouble with this dialogue box is not that it pops up, that's a _GOOD_ thing, rather that it doesn't do what it's told. When you click close, it closes, and then, before you can do ANYTHING else, reappears. This gives the user the impression of a virus and that they can't do anything else in the application. Fortunately that's not true, you can still access the app behind the dialogue, though I'd argue that you shouldn't be able to. The reason behind this is that it is constantly trying to connect to the device the entire time. If you plug the port back in, the dialogue closes itself. This is equally bad. What _SHOULD_ happen is that when the failure occurs, after X retries and whatever other searching goes on, it should stop trying and present the dialog. The dialogue should have retry, and go offline/ignore modes in it, not "close" so that you get what you click. Retry will give the current behaviour (almost) and go offline will give what you'd expect from "close". The only exception should be that it now won't be trying behind the scenes anymore. This could still be done, provided that it's visually indicated to the user while the dialogue is up, and that if "ignore" is clicked, it is honoured.
2012-04-06 23:04   
There is other similar stuff surrounding this with respect to unspecified devices and a sort of urgency to attach to something that is apparent. My configuration currently rules testing that out, but I might perform those tests and comment in future, or others can.
2012-04-07 12:37   
The problem with stopping is that it will lead to a serial and application deadlock.