Trim Sw and Trainer switches about gruvin9x

[GoogleCodeExporter]

No problem. My concern is that I have seen too many times people using the same 
switch for both trainer function and instant trim function. Then I thought it 
would be better to have these switches configured in the same screen so that 
they know what they do.

My idea was to remove this TrimSw from the model setup screen, right! But I can 
leave it as it is, you decide!

No problem for the "Trims to Offsets". It's somewhere in my workspace.

Only reports then, could be quick. Let-me know what you would like to see here!

Bertrand.

Original comment by [email protected] on 4 Oct 2011 at 8:10

[GoogleCodeExporter]

Ah yes I remember now about the same switch for multiple things issue. It is a 
valid point. Hmmm. I'll sleep on it.

Cam, are you reading this? Care to venture an opinion?

In the past, we have tended to sort of 'catch' ourselves doing the task of 
trying to prevent others doing silly things and realised that the project 
shouldn't suffer for the sake of silly things people haven't actually done yet. 
(If you get my meaning.) My thinking now, before I sleep, is tending that way. 
Comments welcomed.

Original comment by [email protected] on 4 Oct 2011 at 9:56

[GoogleCodeExporter]

Ok then, it seems urgent to wait a little bit :)
Bertrand.

Original comment by [email protected] on 4 Oct 2011 at 10:03

[GoogleCodeExporter]

Yes indeed. We must hurry up and wait, quickly and we must wait without further 
delay! :P

I really cant decide. On the one hand, I really want to have the trainer switch 
assignment on the trainer screen. On the other hand, it is too easy to forget 
that instant trim is configured and try to use the trainer function. Also, 
trainer activation should be a model set-up decision, not global.

I thought of all kinds of complex ways to try and protect users from accidental 
double-assignment. Nothing much seems practical.

It simply remains that Instant Trim is a very, very dangerous function. That 
and only that is the real problem here. I really don't like that just one 
dangerous function forces us to make the rest of the project difficult to 
understand. 

My preference would have been to move the trainer switches back to the TRAINER 
screen and leave Instant Trim in Function Switches. Since Instant Trim is the 
dangerous function, it should be that function that takes on the responsibility 
to be safer, if it can. Therefore, Instant Trim should examine the Trainer 
Switches and if it is assigned to the same switch as any of the trainer 
assignments, it should NOT activate. Perhaps it could have a little '!' appear 
next to its switch assignment, too? But no, this doesn't really work because ..

This is still problematic, because the TRAINER stuff is in the global set-up 
menus, not model menus. Clearly, the activation of trainer or not should be on 
a per model basis, not global -- but the actual configuration of the PPM_IN 
system probably should still be global. So once again, we arrive back at having 
trainer activation in the per model Function Switches menu.

Bottom line? I guess it has to stay how it is now -- but mostly because trainer 
activation needs to be per model, much less because of anything to do with the 
very dangerous Instant Trim function.

Original comment by [email protected] on 4 Oct 2011 at 9:36

[GoogleCodeExporter]

TrimSw removed to be consistent with current state.
Trims2Offsets needs to be reported back.

Original comment by [email protected] on 7 Oct 2011 at 5:29

• Changed state: Started

[GoogleCodeExporter]

Trims2Offsets re-added. Shouldn't we open a new issue to avoid mixing 
everything between stable and future release?

Original comment by [email protected] on 10 Oct 2011 at 9:51

[GoogleCodeExporter]

Yes -- always. But this was needed for stable release, because there's people 
here waiting for it who use that feature! (Much to my disgust. :P)

This issue is finished with. Quoting from above ...

"Bottom line? I guess it has to stay how it is now -- but mostly because 
trainer activation needs to be per model, much less because of anything to do 
with the very dangerous Instant Trim function."

Original comment by [email protected] on 10 Oct 2011 at 9:12

• Changed state: Fixed

[GoogleCodeExporter]

It was already per-model you know, remember the traineron bit in the model 
structure.

Original comment by [email protected] on 10 Oct 2011 at 9:25

[GoogleCodeExporter]

Yes, I realised that later on in the above text, I believe. That's why it made 
so much sense to keep things as they were.

Original comment by [email protected] on 10 Oct 2011 at 9:56