Consider ways to make deleting models more safe

[GoogleCodeExporter]

When a model is deleted, another model in the list is immediately loaded. 
There's a warning about doing this in the existing ER9X User Manual, since if 
an electric model is powered up (or a nitro model with its engine running) is 
'listening', bad things could happen. Not likely for a nitro model, but could 
happen more frequently with otherwise silent electrics.

One idea I had was to maybe disable PPM_out whenever a model is deleted and 
then produce a pop-up message saying something like, "WARNING: Model changed. 
OK to enable transmitter?"

There could be problems with some TX modules with this however -- like, some 
might get upset and crash or shut down and not fire up again when the signal 
returns.

Another idea might be to simply add the warning message at the delete 
confirmation. "SWITCH OFF MODEL!" -- or something like that.

Ideas and comments welcomed.

Original issue reported on code.google.com by gru...@gmail.com on 27 Sep 2011 at 6:04

[GoogleCodeExporter]

What about not allowing a selected model to be deleted. So to delete model01 
you must first select any other model. 

Cam.

Original comment by th9...@gmail.com on 2 Oct 2011 at 9:38

[GoogleCodeExporter]

Bertrand actually already has an entire plan for this laid out. As I recall, 
you'll be able to delete any model, but the transmitter will lock and hold its 
last knowing PPM output (rather than switching it off) until you specifically 
choose another model to load up -- that is, if you deleted the currently 
selected model.

On the other hand, your idea (Cam) is even simpler, as it basically gets around 
the entire problem and with much less complexity. What do you think Bertrand?

I should note that the changes Bertrand plans are actually as much to do with 
re-working the user interface for model copy/move/delete as anything else. I 
can't recall if you were privy to that discussion or not. (You should have 
been.)

Original comment by gru...@gmail.com on 2 Oct 2011 at 10:25

[GoogleCodeExporter]

Yes it is a good idea Cam. It simplifies everything.
Will be commited within 2-3 days into darktrain.
Bertrand.

Original comment by bson...@gmail.com on 3 Oct 2011 at 7:41

[GoogleCodeExporter]

Original comment by bson...@gmail.com on 3 Oct 2011 at 7:41

• Changed state: Started

[GoogleCodeExporter]

Oh. I thought the model menu stuff was in frsky too. No big deal if it isn't. I 
guess it is a "new" feature, after all. Does get fuzzy, doesn't it! :P

Original comment by gru...@gmail.com on 3 Oct 2011 at 9:15

[GoogleCodeExporter]

Up to you decide in which version you want it!
One sure thing: it will be in my Tx :)

Original comment by bson...@gmail.com on 3 Oct 2011 at 9:18

[GoogleCodeExporter]

Well, if it's written and it's working, then it can't cause further delays -- 
unless it's buggy :P. So sure, let's have it in frsky, too. *shrug*

I feel we're getting quite close to this stable release for stock radios, no?

Original comment by gru...@gmail.com on 3 Oct 2011 at 12:20

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

Ok then it will be delivered in frsky (next stable version). And it seems to me 
ok if we delivered the asynchronous eeprom write in the same time. This feature 
is really a good point for this version over all others. It has been tested 
successfully by me since more than one week!
Bertrand.

Original comment by bson...@gmail.com on 3 Oct 2011 at 12:26

[GoogleCodeExporter]

Yes, agreed. I have not encountered any problems with the asynch. writes on 
either V4 or the stock radio I've recently been testing for a friend. So lets 
have this important new feature in the stable version. Yay! \o/

Original comment by gru...@gmail.com on 3 Oct 2011 at 9:24

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I see this comment was deleted. Just as well, because I can't make any sense 
out of it. What were you trying to tell me?

But it reminds me to suggest that when you re-write the model list copy/move, 
that a move should fill in an empty slot and not treat such empty slots as 
existing models, such that you can never fill in the empty space when moving a 
model. Hope that makes sense. (It works this frustrating way right now. The 
only way to fill in an empty slot if to move each mode up (or down) one at a 
time. Don't like. James even swore about it yesterday. :P

Original comment by gru...@gmail.com on 6 Oct 2011 at 10:55

[GoogleCodeExporter]

Sorry, I meant that comment #10, to which I was replying, had been deleted.

Original comment by gru...@gmail.com on 6 Oct 2011 at 10:56

[GoogleCodeExporter]

Please wait a little bit, my *deleted* comment was not at all a move operation 
but a delete + a big bug that - yes - could give you this thought ;)

Original comment by bson...@gmail.com on 7 Oct 2011 at 6:37

[GoogleCodeExporter]

Yes OK. But my comments about the move thing were purely based on how ER9X 
works, a I saw it demonstrated that ohter day. I was not talking about your new 
stuff.

Original comment by gru...@gmail.com on 7 Oct 2011 at 9:06

[GoogleCodeExporter]

Understood!

Original comment by bson...@gmail.com on 7 Oct 2011 at 9:12

[GoogleCodeExporter]

Then MOVE operation.
Let's take an example where # is an empty slot: 1 - 2 - # - 3 - 4 
Suppose we want to move 1 down. Er9x would do:
a) 2 - 1 - # - 3 - 4
b) 2 - # - 1 - 3 - 4
c) 2 - # - 3 - 1 - 4
d) 2 - # - 3 - 4 - 1

We have moved 1 where we wanted it, but # has also moved, this is NOT wanted, 
right?

Here is the way I have implemented right now. It may change, depending on this 
discussion of course:
a) 2 - 1 - # - 3 - 4
b) # - 2 - 1 - 3 - 4
c) 3 - 2 - # - 1 - 4 
d) 4 - 2 - # - 3 - 1

I understand you have another idea, right?

Bertrand.

Original comment by bson...@gmail.com on 7 Oct 2011 at 9:19

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hmmm. That's actually quite complex compared to what I had in mind (and quite 
confusing, if you don't mind me saying.)

Here's how I envisaged it ...

We start as ...
*) 1 - 2 - # - 3 - 4

Then move ...
a) 2 - 1 - # - 3 - 4
b) 2 - 1 - 3 - 4  [move "into" the blank spot, taking its place]
c) 2 - # - 3 - 1 - 4 [moves out of the blank spot and 'over' 3]
d) 2 - # - 3 - 4 - 1

The concept is to move in the way one would expect, shuffling things to make 
space BUT when moving "over" a blank slot, first move into it, to take its 
place. If that is not the final resting place, then we move out of the blank 
slot again -- restoring its existence, because we are not actually replacing it 
now -- and continue down the line as normal.

- - - -

Another way of approaching the whole problem would be to simply never allow any 
blank slots to exist in the first place and do not display the slot numbers -- 
a bit like the way the expo screen works, where the list can grow in length 
dynamically, without seeing empty slots waiting to be filled. All new models 
might be forced to be created on the next available line after the last model 
in the current list, then be moved to where they are wanted, maybe. However, 
this will not allow users to have, say, helicopters from 1 to 10, with say, 3 
blank slots in reserve and planes from 10 to 20, just as an example. But if 
users don't actually care about the slot numbers (do they really matter?) then 
they could instead simply focus on the model names.

Personally, I'm not sure either with or without numbers (and therefore never 
blank slots) is better. But I think I would tend toward no numbers at all, 
because really, that is just the way the computer "thinks" being force on the 
human. For example, I do not write numbers on my planes to remember which one 
is which. Do you? ;-)

Original comment by gru...@gmail.com on 7 Oct 2011 at 9:53

[GoogleCodeExporter]

Here is the remove procedure. We want to remove SPLAT which is the current 
model. Then we need to:
1) go to another model
2) make it current [MENU LONG]
3) return to SPLAT
4) select it [MENU]
5) delete it [EXIT LONG]
6) confirm [MENU]

Original comment by bson...@gmail.com on 7 Oct 2011 at 9:53

Attachments:

• snapshot_01.png
• snapshot_02.png
• snapshot_03.png
• snapshot_04.png
• snapshot_05.png
• snapshot_06.png
• snapshot_07.png

[GoogleCodeExporter]

I like that delete function.

Of course, in my idea of removing the number and thus blank slots, models 3, 4 
and 5 would move up to fill the blank space after model 2 was deleted.

Internally, the blank slots could remain, so that we don't have to copy models 
all over the place, which takes a lot of time. By combining my version of the 
move as outlined above with simply not displaying blank slots at all (skipping 
them in the display loop and removing the numbers too) then things should work 
smoothly, without having to copy files around all over the pace and thus quite 
fast, no?

Original comment by gru...@gmail.com on 7 Oct 2011 at 9:58

[GoogleCodeExporter]

I suggest you create a new defect on this MOVE feature. It would allow me to 
commit quicker what I have done now (without changing the actual COPY/MOVE 
feature, which is another chapter)!

Bertrand.

Original comment by bson...@gmail.com on 7 Oct 2011 at 10:39

[GoogleCodeExporter]

Agreed.

Original comment by gru...@gmail.com on 7 Oct 2011 at 11:32

[GoogleCodeExporter]

Done, but needs more testing.
Ready for issue 54 now. I just kept the er9x way of moving models. I already 
changed a little bit the way of copying them. 
To be discussed further in issue 54 then!
Bertrand.

Original comment by bson...@gmail.com on 7 Oct 2011 at 5:28

• Changed state: Fixed

[GoogleCodeExporter]

OK. But this one not working quite right yet. See commit comments r1085.

Original comment by gru...@gmail.com on 7 Oct 2011 at 9:29