Advanced TOC editing - details and others

[icearch]

Moving down is more broken:

let’s say we move ABCD down:



Hitting down once:



sure, work as expected

and hit 2nd times:



like, what happened?

looks like only A moved forward down, left BCD behind.



keeping hitting down till A hits bottom.

So moving down is broken, no matter how careful you are.

[icearch]

And, if you select non-continuous items,
move up still behaves the same,
move down will let each group’s first item keep selected and proceed:

let’s look at this:



hitting down one time:



Two times:



Three times and more:



And just like move up, the item hits bottom stops, but the latter ones keep going.

[icearch]

Let’s see moving up with different level:










Works just like ones with same level, hit’s their parent’s boundary and stops. And each level moves independently.

Moving down same, lost focus expect first item each group, each level works independently.

[icearch]

So, in conclusion:

1. No matter continuous or not, moving up or down, all should stop moving when the most front ones hits boundary. Which is not what happens now.

2. Moving down fundamentally broken ,needs fix.

[icearch]

Let’s see right and left:

First, right and continuous:



hitting right once:



works fine,

And two times:



Ohh, not so good

And keep spamming right:









Mind the last pic, G lost focus.

[icearch]

And more problems, if we keep going, say move H I to right:





Nothing happens till end.

But let’s move it out left:



Once, fine



Twice, they switch? Why?

Keeping hitting left, they keep switching till top level.

But things are not end.

let’s move H and I right again for good measure:



And I becomes children of H.



Keep hitting, and I lost focus.

It’s pretty broken ye?

I don’t know how this happens, But I suspect it have something to do with the bug when moving down.

[icearch]

And when I test moving right with different level:



The software crashes.

[icearch]

And moving right with multi continuous:





Like why?

And the result is random, or to say, depends what you do before you settled down with the final selections, even if the end selections are the same.

Say you Shift the upper group, Ctrl the downer group,
OR you Ctrl every thing,
OR you need to cancel someone,
the result will be different.

[icearch]

And let’s test moving left:



hit left once:



Twice:



I don’t think we need more testing now.

[icearch]

So in conlusion:

1. Only moving one continuous block right once works fine.

[icearch]

In the end, I think my conclusion yesterday is way to hurry. This needs to be revisited and checked thoroughly.

1. I think only let user choose items in the same level and parent is very important, it can saves tons of hassle.

2. The selected block should all stop when the most front one hits the boundary.

3. Moving down and left seems more broken than up and right.

Thst’s it, hopes best.

[KevinH]

In response to your first new post about Moving up:

Originally Posted by icearch

Let’s start with something easy

When moving multi items up, this happens:

let’s say we want to move EFGH to the top.

Attachment 224995

And keep hitting move up 4 times till hit upper boundary:

Attachment 224996

If you be careful and stop here, nothing happens.

But you spam move up a little too hard:

Attachment 224997

See? The item E lost focus ( de-select ), and FGH keep move up.

And keep hitting up:

Attachment 224998

Attachment 224999

Attachment 225000

And F\G\H de-select and left behind, cause it all reverse.

And that is exactly expected behaviour. When you added that extra move, E can not move up since it was at the top, so it purposefully gets dropped from the current selection and the remaining F-G-H get promoted one by one.

This is how the code was designed to work when you incorrectly select something (ie. Selecting E in a multi-selection) when it is already at the top and tellng it to move up.

[KevinH]

In response to your second new post:

Originally Posted by icearch

Moving down is more broken:

let’s say we move ABCD down:

Attachment 225001

Hitting down once:

Attachment 225002

sure, work as expected

and hit 2nd times:

Attachment 225003

like, what happened?

looks like only A moved forward down, left BCD behind.

Attachment 225004

keeping hitting down till A hits bottom.

So moving down is broken, no matter how careful you are.

Yes, this is a bug, the indexes you selected earlier are getting invalidated by something. Not sure what or why but moving a block down multiple times in a row should work. I will track down and fix this.

[KevinH]

In response to your third post:

Originally Posted by icearch

And, if you select non-continuous items,
move up still behaves the same,
move down will let each group’s first item keep selected and proceed:

let’s look at this:

Attachment 225005

hitting down one time:

Attachment 225006

Two times:

Attachment 225007

Three times and more:

Attachment 225008

And just like move up, the item hits bottom stops, but the latter ones keep going.

Again when hitting a boundary you now having an illegal selection (selecting something at the very bottom and telling them to move down) so that part of the selection is automatically dropped as it is an invalid selection. The remaining parts of your selection can and will be moved down. This is how the code was designed to work when illegal selections are made, they are ignored.

[KevinH]

Originally Posted by icearch

So, in conclusion:

1. No matter continuous or not, moving up or down, all should stop moving when the most front ones hits boundary. Which is not what happens now.

2. Moving down fundamentally broken ,needs fix.

About 1: Here we disagree. How it operates with an illegal selection with a multi-selection is to drop the part that is illegal but continue performing any legal selections. Why should a single illegal selection stop other legal items from moving? If a user goes too far, they can easily fix reverse to fix it.

And that is what the code did in all cases of moving up, right and left. In all of your "spamming" cases you had illegal selections in a multi-selection for a move direction you did and just that part was ignored. Nothing in these cases are random. It did what you asked when the move direction hit a boundary with an item that can not move in that direction, and dropped it automatically from the multi-selection.

You seem to think of what you select as a "solid block" that should only move until it reaches an edge. Where-as I conceived them as a collection of selected items that you told to move in a specific direction and it does its best to carry out what you asked on each part of the collection only ignoring something when it is illegal to move in that direction.

So it may be not what you expected but it was exactly what I expected as that was the design of the code. So we will disagree here.

About 2: Agreed. I will look into that.