Model move/copy should not do the move/copy until finally confirmed

[GoogleCodeExporter]

[frsky]
This one is important ...

When moving models from slot to slot in the MODELSEL screen, no file 
reading/writing (EEPROM) should actually take place until the user finally 
confirms the intended move or copy.

Currently, there are long and potentially dangerous (data corruption) delays 
occurring as a model is moved up or down the list. The delays are especially 
(and unacceptably) long where larger model data sets are involved. It's very 
confusing.

There's also a bug in there somewhere, because we've now witnessed three times 
models get unintentionally deleted when we were only moving a model. Have not 
been able to nail down exactly what conditions cause this -- but it would be 
avoided entirely if the above mentioned changes were made.

Again, I consider this one to be really important. 

Additionally, we've somehow gone from very nearly ready for release to suddenly 
several old bugs re-occurring and highly unstable code.

At this time, I have no confidence in the current frsky version. I cannot fly 
with it. I say we should now suspend the two-week countdown until such time as 
we get back to a release candidate status. That means we're right back at first 
Beta stage -- too many things have gone wrong, somehow.

Don't sweat it -- stuff just goes wrong sometimes. It is what it is. However, 
in light of these problems, perhaps we can once again focus full attention on 
this now way overdue stable release -- no more new feature work until it 
settled, once and for all. (It's getting really embarrassing -- in face-to-face 
meetings now.)

Thanks guys.

Gruvin.

Original issue reported on code.google.com by gru...@gmail.com on 19 Nov 2011 at 3:29

[GoogleCodeExporter]

This relates to issue 61. The working/busy need becomes less if this change can 
be made -- but I still think it should come up on screen during the long wait 
period, while data is being saved to EEPROM.

Original comment by gru...@gmail.com on 19 Nov 2011 at 4:03

[GoogleCodeExporter]

Agreed, but first I would like to find the bug. I will try to reproduce it.

Original comment by bson...@gmail.com on 19 Nov 2011 at 8:09

[GoogleCodeExporter]

Original comment by bson...@gmail.com on 19 Nov 2011 at 8:10

• Added labels: Milestone-frsky

[GoogleCodeExporter]

This just in (from local chap, James) ...

I’ve also figured out how the transmitter is deleting models by accident – 
follow these steps
1) Create 3 models
2) Select the 1st model down with the asterix
3) Move the highlighter down to the last/3rd model
4) Fast click Menu once to highlight it
5) Click the down button once – and a copy will be created underneath the 
model list – (Now dont do anything more and think about whats just happened)
6) Now press exit once and quickly and wait 10 sec
7) Now press the exit button once more and wait 10 sec – sometimes you can 
now see the model being deleted and others it will exit to the mail screen
8) If it exits to the main screen wait a few seconds and then click the right 
button in the round button section to go back to the model list and you should 
see a model will be missing

Original comment by gru...@gmail.com on 19 Nov 2011 at 11:23

[GoogleCodeExporter]

Thanks Bryan, if I succeed to reproduce it, 90% of the work is done.

Original comment by bson...@gmail.com on 19 Nov 2011 at 11:26

[GoogleCodeExporter]

A little correction to what has been said above, moving a model is NOT 
something big, we only rewrite the 64 first bytes of the EEPROM.

Original comment by bson...@gmail.com on 19 Nov 2011 at 11:28

[GoogleCodeExporter]

Reproductible on simu. Awesome!

Original comment by bson...@gmail.com on 19 Nov 2011 at 12:53

[GoogleCodeExporter]

Solved. The bug was here since one month. Not seen by anyone. Could explain 
some crashes in all menus (since we were writing on a deleted model).

Original comment by bson...@gmail.com on 19 Nov 2011 at 1:27

• Changed state: Fixed

[GoogleCodeExporter]

Yes, I too realised it must have been there some time. Strangely, none of my 
testing on the bench at home revealed it. But by being under more 'pressure' at 
the field, clicking around thing more quickly, it showed up several times.

Well done!

Original comment by gru...@gmail.com on 20 Nov 2011 at 12:46