Notes |
|
|
Nope, not going to be done, end of story and here's why:
Each tab is extremely likely to have data on it from MULTIPLE LOCATION ID's (or pages in the case of MS), and having to break out which ones and which data areas, and which can be read in subsets and which cannot is NOT WORTH THE HASSLE, and offers next to ZERO positive value, and only serves to confuse.
Megatune used to have this sort of behavior (it sucked ass), and it forced each window to ONLY allow controls from a single page (location ID), and got people into the very bad habit, of clicking fetch, changing somethign nad burn over and over again, which cal lead to premature flash failure, as well as a very clunky user experience..
Marking as low/no priority, as there's no compelling reason of value based in reality for this |
|
|
(0000946)
|
Fred
|
2011-12-08 13:19
|
|
Leaving assigned to no-one such that someone else can pick up the task if they feel the urge. Resetting to open for same reason. See IRC for more info. |
|
|
(0000947)
|
Fred
|
2011-12-08 13:22
|
|
"Megatune used to have this sort of behavior (it sucked ass), and it forced each window to ONLY allow controls from a single page (location ID), and got people into the very bad habit, of clicking fetch, changing somethign nad burn over and over again, which cal lead to premature flash failure, as well as a very clunky user experience.." = Flawed implementation. |
|
|
|
The only way to accomplish what you want is to limit the controls on a active page/tab to be all from the same page or location ID. That ruins the UI experience and severely limits the usability, or expoenentially increases complexity of data management and leads to much more bugs and much harder resolution of such bugs. |
|
|
|
If you returned something in the datalog stream indicating which location ID's were stale it would be far easier. i.e. Set a flag (burn needed/outstanding data, etc), and the tuning software could then do a sweep comparing flash to ram per location to determine what is not current. Right now, you don't do that, which causes the problem if the tuning software/host computer/e5tc were to die, and reconnect it would NOT have any idea that things were out of sync (no flags from ECU), and it would put hte onus on hte tuning software to figure it out. In the case of other ECU's it is NOT POSSIBLE to read he flash and ram states independently, hence what you original wanted in a previous not was never able to be created. a FLAG in the serial stream is the nicest way to give the tuning end a heads up, its also useful in a datalog scenario as a historical marker as to when burns occur (the flag will flip state then, when all locations match), and that can be used to correlate if burns disturb other runtime actions (wheel decode for example) |
|