Unexpected caret movement in current directory

[yyang]

Today I noticed an unexpected caret movement during text selection from the "current directory" field. Say my current directory was "D:\Tmp\test\", and I just wanted to copy "\test\". Then I highlighted the field, positioned the caret to the end (with nothing selected), and pressed "Ctrl-Shift-Left". After that "test\" was selected. Then I pressed "Shift-Left", expecting to include the "\" to the left of "test" into the selection, but it turned out the trailing "\" was deselected! That's quite weird behavior, and I can hardly believe it's by design. The same problem exists with the command-line field.

[petermad]

Confirmed - and I agree - it is an unexpected behaviour that the cursor is not moved when pressing Ctrl+Shift+Left - especialy because it is moved when pressing Ctrl+Shift+Right.

[ghisler(Author)]

This ahs been discussed many times. Currently there is no solution because there is no way on Windows to set both the selection AND the caret location within an edit field.

[petermad]

How come it works for Ctrl+Shift+Right then ?

[StatusQuo]

2petermad
The problem seems to be, that Ctrl+Shift+cursor functions always set the caret/cursor to the right side of the selection, while it can expand/shrink to both sides (start or end of selection).
In contrast to Shift+cursor, where the start of the selection is fixed and the cursor moves normally like in non-select mode.
I think it's luck, that these behaviours fit each other while selecting left to right, correct?

To see the problem one might try the other way:

• set cursor in the middle of a pathname
• press Shift+Left to mark some characters to the left (you can see the caret/cursor on the left side of the selection)
• press Ctrl+Shift+Right => the cursor (first?) jumps to the right end of the selection and (then?) expands the selection to the right side

2ghisler(Author)

Currently there is no solution because there is no way on Windows to set both the selection AND the caret location within an edit field.

Can you
- set the caret location alone
- get the info, where the start/end positions of the current selection are
?

Then maybe "normal" behaviour could be emulated in few extra steps:

• store/remember, if the cursor is on the left or right side of the selection
• do the selection change as usual
• if the actual (changed) right position of the selection is the same as before the change:
  • set the cursor to the side it was on before the change

[petermad]

The problem seems to be, that Ctrl+Shift+cursor functions always set the caret/cursor to the right side of the selection,

Not exactly - Ctrl+Shift+Up and Ctrl+Shift+Down doesn't.

In the current path field you can actually use Ctrl+Shift+Up to do the same as Ctrl+Shift+Left BUT the caret is then moved correctly!

Unfortunately you cannot use that workaround in the command line. Here Ctrl+Shift+Up does nothing and Ctrl+Shift+Down opens the dropdown list of previous commands.

It actually even seems like TC knows where the cursor is supposed to be when using Ctrl+Shift+Left, because if you press Ctrl+Shift+Left once and then press Ctrl+Left then the caret doesn't jump to the boundary immediately to the left of the selection, but it jumps to the next boundary to the left. On the other hand, if you just press Left after one press of Ctrl+Shift+Left then the caret moves one character left with an offset to the visible position.

[StatusQuo]

In the current path field you can actually use Ctrl+Shift+Up to do the same as Ctrl+Shift+Left BUT the caret is then moved correctly!

Yes (quite interesting), but the cursor doesn't stop at any "" then.
So I assume, there (in the current path field) the "old" method of text selecting is used for Ctrl+Shift+Up / Ctrl+Shift+Down?

It actually even seems like TC knows where the cursor is supposed to be when using Ctrl+Shift+Left, because if you press Ctrl+Shift+Left once and then press Ctrl+Left then the caret doesn't jump to the boundary immediately to the left of the selection, but it jumps to the next boundary to the left.

Strange, indeed.

[petermad]

but the cursor doesn't stop at any "\" then.

Hmm - here it stops at _ \ . and space when using Ctrl+Shift+Up/Down.

Could you please try again?

[StatusQuo]

but the cursor doesn't stop at any "" then.

Hmm - here it stops at _ \ . and space when using Ctrl+Shift+Up/Down.

Could you please try again?

You're right, this effect seems to depend on the "AutoComplete" option in WINCMD.INI (TC 7.02a):

In actual path line
- AutoComplete=0: disabled, enhanced stopping at special characters like _ \ . NOT active
- AutoComplete=1 or 2 or 3: enhanced stopping active

P.S.: This gives me hope, that disabling the new cursor selection/stopping mode globally may be possible in a future version...

[ghisler(Author)]

In TC 7.03, you can now switch to the standard Windows selection method if you prefer. Form history.txt:

Let user choose between internal Ctrl+Arrow key movement and Windows edit box movement:
wincmd.ini
[Configuration]
CtrlArrow=0

[roentgen]

CtrlArrow=0

This disables Ctrl+Arrows stopping at word separators (- _ .) in dialogs like F5 - copy. At least in XP this is expected to work.

[StatusQuo]

CtrlArrow=0

This disables Ctrl+Arrows stopping at word separators (- _ .) in dialogs like F5 - copy. At least in XP this is expected to work.

Hm, I would not expect that - even while renaming in Explorer the cursor does NOT stop at these characters here (- _ .).
Tested with XP SP2 Home.

2ghisler(Author)
Thanks very much for implementing this.

[roentgen]

Hm, I would not expect that - even while renaming in Explorer the cursor does NOT stop at these characters here (- _ .).
Tested with XP SP2 Home.

It works in explorer's address bar, Start>Run dialog and in Open/Save dialogs.

[StatusQuo]

[...stop characters...]

It works in explorer's address bar, Start>Run dialog and in Open/Save dialogs.

Right, the same here. Maybe TC uses a type of edit box/control here, that doesn't support this?

BTW, alternative while having CtrlArrow=1: additionally holding down the Alt key temporarily switches to standard windows cursor movement -
but this ignores the stop characters (- _ .), too.

[ghisler(Author)]

It works in explorer's address bar, Start>Run dialog and in Open/Save dialogs.

Indeed it works with Ctrl+Arrow movement also in Explorer bar and TC 7.5 command line. My tests seem to indicate that this is a feature of the Unicode edit box, but ONLY when auto-complete is turned on!