[TC11.55rc5] Custom columns editor, bad fix for arrow buttons

[white]

21.10.19 Release Total Commander 9.50 beta 2
..
18.10.19 Fixed: Custom columns dialog: Program was hanging when clicking behind custom column options (64bit). Solution: Set up/down button already when just moving the mouse, not when clicking (32/64)

Before the fix, the up/down buttons would only be visible for the "active column" (meaning the row that has focus ). Clicking at the end of an inactive row, made that row active.

After the fix, hovering over the up/down buttons makes the row active, but the cursor remains where it is. So it looks like another row is still the "active" one, while it isn't. When Using Ctrl+PgUp/PgDn (move row) or Alt+D (delete active row), the row is moved/deleted where the mouse last hovered over the up/down buttons, not where the cursor is. This is not clear at all.

[ghisler(Author)]

I think it's quite clear that Ctrl+Page Up/Down works on the row which has the up/down button, not the one which has the focus. Moving the cursor would probably cause new lockups, therefore I prefer not to change this, sorry.

[white]

I think it's quite clear that Ctrl+Page Up/Down works on the row which has the up/down button, not the one which has the focus.

No, it's not. Note that on Windows 11 the arrows are hidden when the mouse is not over them, making the control not very visible. Also, it's very weird that hovering over the controls changes the active row while the cursor is somewhere else. Why doesn't this happen when hovering over the other controls?

And if you want to scroll the list and don't want to change the active row, you need to carefully move your mouse all the way up or down and go around all (hidden) up/down buttons to reach the scroll bar before you can use the scroll bar. That's quite insane.

Also note that while 32-bit TC autoscrolls the active row into view when you move the row up or down, 64-bit TC does not. Suppose you have many columns, so you have a scroll bar. You then move a row down by pressing Ctrl+PgDn repeatedly until it disappears from view (64-bit TC). You then click somewhere on the bottom of the scroll bar to go a page down until the moved row is in view. You then want to continue moving the row by pressing Ctrl+Dn, but a row somewhere in the beginning out of view is now active because you did carefully make a detour with your mouse to avoid any hidden up/down buttons.

Moving the cursor would probably cause new lockups, therefore I prefer not to change this, sorry.

It better to not change the active row at all. It used to work that way. The active row only changed when you clicked one of the controls in that row. The help still says:

Allows you to sort the columns manually. Place the cursor in the column which you want to move, and two small arrow buttons will appear. Now click the Up or Down arrow button multiple times to move the column.

That's no longer how it works, and the mouse hint "Move active column" makes no sense anymore.
If the (hidden) up/down buttons pose a problem when clicked upon, why not simply do nothing when the user clicks on them when the row is not active? Would that also cause a hang?

[ghisler(Author)]

It better to not change the active row at all.

That could work, I will try it - move the scroller but not the active row.

[ghisler(Author)]

This should be fixed in RC6, please test it!

10.06.25 Fixed: Configure custom columns: Ctrl+PageUp/Down will now always move the line with the cursor, not the one with the scrollbar (32/64)

About this report:

Also note that while 32-bit TC autoscrolls the active row into view when you move the row up or down, 64-bit TC does not.

This seems to be missing in Lazarus, so I added it manually (also in find files):

10.06.25 Fixed: Find files, Plugins tab: Scroll line into view when sorting (64)
10.06.25 Fixed: Configure custom columns: Scroll line into view when sorting (64)

[white]

10.06.25 Fixed: Configure custom columns: Ctrl+PageUp/Down will now always move the line with the cursor, not the one with the scrollbar (32/64)

Tested OK. Since you use the changelog also to inform users, may I suggest a more descriptive changelog entry:

10.06.25 Fixed: Configure custom columns: Ctrl+PageUp/PageDown now always moves the row where the focus is, not the row where the up/down buttons for row movement appear after hovering over the end of another row (32/64)

The current implementation still feels weird though. Could the up/down buttons for row movement be hidden again (and those on the focused row shown again) when the user does not click on the control but moves the mouse away from it?

And why does the control get focus when clicked, and can be moved with the Up/Down keys? Whilst it is not visible that the control has focus, the control is not in the tab order, and using the Up/Down keys is undocumented.

About this report:

Also note that while 32-bit TC autoscrolls the active row into view when you move the row up or down, 64-bit TC does not.

This seems to be missing in Lazarus, so I added it manually (also in find files):

10.06.25 Find files, Plugins tab: Scroll line into view when sorting (64)
10.06.25 Fixed: Configure custom columns: Scroll line into view when sorting (64)

"10.06.25 Find files, Plugins tab: Scroll line into view when sorting (64)" -> tested OK.

"10.06.25 Fixed: Configure custom columns: Scroll line into view when sorting (64)" -> Doesn't work when the keyboard is used instead of the mouse.

It would be nice if the automatic scrolling would also work when you repeatedly press Tab or Shift+Tab.

[ghisler(Author)]

Tested OK.

Great, thanks! I will use your better description (I didn't want to make it THAT long originally...).

Could the up/down buttons for row movement be hidden again

It's not hidden when a line has the focus. When you move the mouse so it changes position and then use Ctrl+PageUp/Down again, it jumps to the moved line. I have thought about moving it back to the line with the focus when the user moves the mouse away, but that would look strange.

And why does the control get focus when clicked, and can be moved with the Up/Down keys?

That's because the control is actually a scrollbar, which
- can get focus
- will react to cursor keys the same way as when the user clicks on the buttons

"10.06.25 Fixed: Configure custom columns: Scroll line into view when sorting (64)" -> Doesn't work when the keyboard is used instead of the mouse.

Confirmed, I didn't try that.

It would be nice if the automatic scrolling would also work when you repeatedly press Tab or Shift+Tab.

I will add it.

[white]

Could the up/down buttons for row movement be hidden again

It's not hidden when a line has the focus. When you move the mouse so it changes position and then use Ctrl+PageUp/Down again, it jumps to the moved line.

But when the mouse is still at the same position (over the up/down buttons), it jumps back to the mouse again. On 32-bit TC this always happens. On 64-bit it happens only the first time you press Ctrl+PageUp/PageDown, not when repeatedly pressing Ctrl+PageUp/PageDown.

I have thought about moving it back to the line with the focus when the user moves the mouse away, but that would look strange.

Right now, you seem to have implemented it using 1 scrollbar for moving rows. And you move that scrollbar around. I think you should work with 2 scrollbars. One for the active row (which stays visible as long as a control in that row has focus, and has the hint "Move active column"), and an additional scrollbar shown when hovering over inactive rows (this one is removed on the mouseout event if the row is not the active row, and has no hint).

And why does the control get focus when clicked, and can be moved with the Up/Down keys?

That's because the control is actually a scrollbar, which
- can get focus
- will react to cursor keys the same way as when the user clicks on the buttons

Whether it receives focus when clicked upon depends on the TabStop property. Right now it is set to true and its tab order is in between the Apply button and the Width field of the first row (which is not obvious for the user at all).

I think you should make a choice. It seems you meant for the control to be controlled by the mouse and that you added Ctrl+PageUp/PageDown for keyboard support. I think it should either not have a tab stop, or have a tab stop and have a tab order at the end of the row where the scrollbar is currently positioned (so changing the tab order when it is moved to another row).

BTW, why are the up/down buttons removed when the + button gets focus? Is it because the user might otherwise expect he can press Tab to reach the control when the + button has focus?

[ghisler(Author)]

But when the mouse is still at the same position (over the up/down buttons), it jumps back to the mouse again.

This happens when TC receives a "mouse move" event. I can't know whether this is caused by real mouse movement, or jittering of the mouse sensor (especially when it's very sensitive).

I think you should work with 2 scrollbars.

Sorry but that would be very confusing.

Is it because the user might otherwise expect he can press Tab to reach the control when the + button has focus?

Yes, exactly! The control is meant to be used with the mouse. I show it even when not hovering there so the user knows that this option exists.

In conclusion, I prefer not to change the current behaviour except for the auto-scrolling part. We could think about redesigning the whole dialog, but not at this time. The beta test for 11.55 has been going on far too long already.

[white]

In conclusion, I prefer not to change the current behaviour except for the auto-scrolling part. We could think about redesigning the whole dialog, but not at this time. The beta test for 11.55 has been going on far too long already.

Fair enough. I think the dialog does indeed need a redesign in the future, which probably will involve removing the current complex behavior.

The texts of the help text, buttons and hint, also need improvement. I think the use of the word "column" can be quite confusing for users when presented with actions on rows of controls in the dialog. And speaking of an "active column" indicating the row containing the control that has focus, is simply wrong. I understand that a similar way of wording is used as in the change attributes dialog ("More attributes" and "Fewer attributes") and the search dialog's plugin tab ("More rules" and "Fewer rules"), but this outcome-based wording doesn't work for this dialog. First, because "column" is ambiguous in this context. Second, because when using the word "active" you are referring to graphical elements in the dialog, not what is configured by it. If the other dialogs would be adjusted to have similar functionality, saying "active attribute" or "active rule" would be wrong too.

[white]

It would be nice if the automatic scrolling would also work when you repeatedly press Tab or Shift+Tab.

I will add it.

Tested using private version TC 11.55rc6a 64-bit.

Pressing Tab repeatedly -> Tested OK.

Pressing Shift+Tab repeatedly
-> Scrolls 2 rows instead of 1 (perhaps on purpose?)
-> Doesn't scroll when it reaches the up/down buttons to adjust the width of the "Ext" column.

When hovering with the mouse over the end of inactive rows:
-> When slowly (!) moving out of the up/down buttons for row movement, at the top/bottom/right (not at the left), the control jumps back to the active line (which I rather like).

[ghisler(Author)]

Doesn't scroll when it reaches the up/down buttons to adjust the width of the "Ext" column.

Currently it doesn't scroll for any of the up/down buttons, e.g. when one is half visible and you click on it. I will add it.

When slowly (!) moving out of the up/down buttons for row movement, at the top/bottom/right (not at the left), the control jumps back to the active line (which I rather like).

Not only when slowly hovering between the buttons (because there is a small gap), but also when hovering over other controls. Currently it doesn't move the button back when you move away the mouse very quickly, so the dialog doesn't see any more mouse events. I could do this with a timer, but I think it's a bit overkill. As soon as you move the mouse back, the up/down button will move.