Total Commander

HISTORY.TXT wrote:05.11.2018 Added: Synchronize dirs: Use Ctrl+PageUp/PageDown to jump to next/previous directory (32/64)

Very useful addition - but shouldn't this set the cursor to the directory just jumped to?

Purpose for updated cursor position would be:
Jump to next directory > see that it's not relevant > right-click (ContextMenu key / Shift+F10) > Remove selection (Ctrl+M) > Jump to next dir.

Now this requires an additional mouse click and is not achievable using the keyboard?

Current situation after jumping to the next directory this way (TC 9.50):

• pressing cursor up/down jumps back to the old position
• hotkeys (Ctrl+M/Ctrl+L/Ctrl+R/...) and right-click context menu work on the old cursor position,
  so are altering settings for files not currently displayed.

Additionally: Currently the hotkeys have no effect, if all differences fit on the screen (as the content can't be scrolled).

shouldn't this set the cursor to the directory just jumped to?

That's a good idea, I will add it.

Currently the hotkeys have no effect, if all differences fit on the screen (as the content can't be scrolled).

This happens because TC looks for the first directory below the top position and tries to scroll that to the top. When already at the end of the file, this will not have any effect. The idea is just to scroll the next directory into view, which is useful when there are very long directories.

12.02.2020 Release Total Commander 9.50a release candidate 1 (RC1)
09.02.2020 Fixed: Synchronize dirs: Ctrl+PageUp/PageDown to jump to next/previous directory didn't set focus on header (32/64)

Unfortunately this introduced dangerous selection problems when using the keyboard.
It only seems to work as expected when using the mouse (right-clicking the directory header line - but then Ctrl+PgDn does not need to set the cursor focus).

In TC 9.50 final this was at least safer (one can see that the selection is not where it's expected, so there is probably no surprise after applying changes by mistake to files outside of current view).
Fixing the below keyboard selection issues would be nice, but reverting to previous behaviour (in TC 9.50 final) would be a valid option for me, too.

To reproduce:
1)

• set test dirs, e.g. left = %windir%\system32\Cursors (something with no sub-dirs), right = %COMMANDER_PATH%
• start Commands > Synchronize Dirs
• set [X] Subdirs
• press "Compare" button (=> cursor is on first file)
• press Ctrl+PgDn > Apps-key (context menu) > Remove selection

=> markers in selected subdir are removed OK, but: use mouse / scroll bar to scroll back to the top for having a look:
also the first file is still selected, so the direction marker is changed/removed there, too.
Very dangerous when setting a copy direction...

2)

• 2x press Ctrl+PgDn (select the second sub-dir) > Apps-key (context menu) > Select for copying (default direction)
• use mouse / scroll bar to scroll back and check the selection:

=> the contents of the second dir didn't get selected at all, previous selection stayed unchanged (the last used dir + the very first file on the top).

It only moves the cursor, it doesn't remove the selection. How would you change that?

The Apps key should remove the old selection, if pressed while cursor focus is outside of the current selection (as it creates a new selection there). This is what right mouse button does.
If the cursor focus is inside the selection (file or dir header), no selection change is needed before showing context menu.

If that's not possible, cursor focus should better stay unchanged on the old position (Ctrl+PgDn/PgUp only scrolling the list).
(Which would be not ideal for keyboard users, but no big deal - and irrelevant for mouse users.)

Unchanged selection is perfectly fine when only jumping/scrolling (useful to extend the selection with Shift + left mouse).

What if a range of files is selected, and the cursor is on one of them? Remove selection from entire range, or just from the cursor?

ghisler(Author) wrote: 2020-02-14, 14:40 UTC What if a range of files is selected, and the cursor is on one of them? Remove selection from entire range, or just from the cursor?

If the cursor is on one of them, the selections should not be changed at all (so context menu can work on the selected items).
Basically: If the Apps key has to add a new line to the selection range(s), the old selections should be removed first. Otherwise it can work with the existing selection(s).
(Just like right mouse button.)

Could this feature please be fixed (i.e. Apps key to behave like right mouse button) or removed (so not updating cursor position)?

The current behavior can unintentionally overwrite data.
(What's the advantage of updating the cursor position, if the apps key is not usable?)

AHK: old workaround, modifying Apps key behavior with mouse assistance

Possible AHK workaround (before using: place mouse cursor over the first line, where the directories are scrolled to):

Code: Select all

#IfWinActive, ahk_class TCmpForm
AppsKey::
+F10::
	MouseClick, Right
	Return
#IfWinActive

This should solve it for any of the three possible solutions.
Though I wouldn't feel comfortable to enroll TC with the current implementation to workstations without this fix.

Edit:

AHK: fix/more convenient workaround, removing old selection before Apps key creates a new one

Code: Select all

#IfWinActive, ahk_class TCmpForm
~^PgDn::
~^PgUp::
	TcSyncRemoveOldSelection()
	Return
#IfWinActive
TcSyncRemoveOldSelection()	; https://www.ghisler.ch/board/viewtopic.php?p=369646#p369646
{		; *** fix target selection for Apps-key/Shift+F10 (auto-remove old selection before Apps key creates a new one, after jump-to-next-dir)
	sTcSyncRemSel_NoChangeHotkey := "Shift"	; *** prevent selection change by pressing this hotkey before releasing the Ctrl key (e.g. Shift, LWin)
	;
	static boTcSyncJumpDirRunning = 0
	if (boTcSyncJumpDirRunning)	; *** prevent simultaneous calls/multiple executions for different hotkeys
		Return
	boTcSyncJumpDirRunning = 1
	KeyWait, Ctrl	; *** prevent flicker (+ optionally keep selection unchanged by pressing Apps key once while still holding down Ctrl key)
	GetKeyState, boPreventSelChange, %sTcSyncRemSel_NoChangeHotkey%, P
	boPreventSelChange := (boPreventSelChange = "D")
	if !(boPreventSelChange)
		ControlSend, TBkGndListBox1, {Down}{Up}, ahk_class TCmpForm	; *** remove old selection by sending Cursor-Down + Cursor-Up
	boTcSyncJumpDirRunning = 0
	Return
}

2ghisler(Author)
May I ask if something is planned about this?
Maybe this thread should better be split to forum "bug reports" or "behaviour which will not be changed"?

Both problems above are still present in TC 9.51 RC5 and RC6:

• The serious one on first use after Ctrl+PageDown:
  Context menu via keyboard (Apps-key / Shift+F10) also applies to old selection/previously selected files => wrong files may get overwritten/deleted
• Inconsistent, but not harmful:
  Context menuy on a directory header (for all files inside) can only be used once. Using it again on another header line does not select any file.

My suggestion for an easy solution of issue 1 would be:
adding a "RemoveSelection" before the code that's selecting all files of a right-clicked folder.
This could fix the "unwanted selection" keyboard problem without affecting the mouse behavior, that already has this functionality.

adding a "RemoveSelection" before the code that's selecting all files of a right-clicked folder.

I regularly select groups of lines for copying, so removing the selection is a bad idea. Any better ideas?

ghisler(Author) wrote:Any better ideas?

Idea #3:
If (the focus situation is like after Control+PageDown) with cursor focus on a folder header line:
do NOT auto-select folder contents by pressing Apps-key or Shift+F10.
(only auto-select if there is just one single selection on the folder header; mouse behavior unchanged).

#3 should eliminate the danger of data damage (issue 1), be more consistent (issue 2) and does not alter existing selections (your concern).


The older ideas:
Idea #0: revert Ctrl+PageDown to only scrolling, without moving the cursor focus away from the selection.
Idea #1: Identical context menu behavior for keyboard and mouse is what I would prefer (most intuitive).
Idea #2 (above post):

I regularly select groups of lines for copying, so removing the selection is a bad idea.

I think I took that into account, my suggestion should not remove any selection that mouse usage wouldn't remove as well:

• Right-clicking any file does not call the "auto-select-all-contents" function,
  so the added "RemoveSelection" there is not executed either, no change of selection treatment in this case.