FreeEMS Issues - Tunix |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0000251 | Tunix | FreeEMS Plugin | public | 2011-08-27 18:37 | 2011-11-18 20:56 |
|
| Reporter | Fred | |
| Assigned To | dandruczyk | |
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | |
| Platform | All | OS | All | OS Version | All |
| Product Version | | |
| Target Version | 0.9.24 | Fixed in Version | | |
| FirmwareVersion | |
|
| Summary | 0000251: App Swallows FreeEMS Errors Instead Of Displaying Them To The User |
| Description | I don't get popups when i intentionally cause a firmware error response, instead of the desired action, nothing happens. In general, if there is an error from the firmware, i want the user to see it.
In the case where its repetitive, ok, there is a problem that needs solving, and maybe a "don't show this error again in the current session" option would be good. But they really need to be told what is going on.
In most cases an error from the firmware = incompatible, a bug in mine or a bug in yours, all of which we need to know about ASAP, and having the user say "got error 345" is a good way of finding out AND understanding why in one go.
In other cases, though, it's legitimate that you get the error, and it tells you that you did something wrong using the app/fw, a wrong value or some such thing. Those errors are user errors as much as they are dev errors and should be passed on.
We should have a set of pretty messages for them, and display number, name, and message in a dialog and log it to a file also. We need to hear about it, and that's the only way it'll happen, IMO.
Right now you output the error to the console, that'll do for now, but the user, who may launch from a menu, should see it too. |
| Steps To Reproduce | Enter value of 2-100 in any PW field of the bench test decoder tab and hit send. |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
Notes |
|
|
|
Dude, look in hte terminal where mtx is started
Packet ERROR Code 0x7778, "Too short of a PulseWidth to test!"
ERROR with Bench test packet!
So its not in the Gui YET.. it DOES WORK. |
|
|
|
(0000240)
|
|
Fred
|
|
2011-08-28 14:23
|
|
From the issue body: "Right now you output the error to the console, that'll do for now, but the user, who may launch from a menu, should see it too."
Yep, I noticed that! :-) And yep, great that it's there! This is just a TODO item, really. |
|
|
|
|
|
added messagebox to the benchtest window that reports issues to the user specific to those packets. |
|
|
|
(0000244)
|
|
Fred
|
|
2011-08-28 15:34
|
|
Excellent, tested and works well! :-)
Do you plan to have errors broken down into different categories with different handlers like an exception hierarchy? and only allow "unknown" ones to float up to a popup? if so, that would be very cool. ie, bench test stuff goes to the little text area, and other things to various other places such as warning lights in some fancy gui UI and random stuff that shouldnt happen comes to a popup? |
|
|
|
(0000613)
|
|
Fred
|
|
2011-11-18 19:57
|
|
|
Bump, I'd like to see this being more obvious/annoying with a window to display certain bad ones and a list like the bench test one somewhere where we can watch it all the time, a small separate window maybe? One vote for more work on this! :-) |
|
|
|
|
|
You bitched left and right about the popup errors, so I'm not going back to that.... |
|
|
|
(0000617)
|
|
Fred
|
|
2011-11-18 20:56
|
|
I bitched about pop up errors that can't be turned off on an individual basis with hard coded behaviour, Dave! Especially about ones that I couldn't give two hoots about, and that are part of features that I never use...
Besides, if you read the comment you'll see that i suggested other things. Anything should be suppressible...
Don't assign back to me or change the status until this is handled in some form :-p |
|