command line selection

[seb]

i recognised strange behaviour:

i am over some file and copy the complete path using CTRL+SHIFT+Return to the command line
i enter the command line and start selecting parts of it via CTRL+SHIFT+LeftCursor
when the file is completely selected, TC starts deselecting at the end...
this was working all the years, now that changed

where can i get the old behaviour back?

its pretty disturbing when you used this to select the whole name

[StatusQuo]

Confirmed and support+.

Already reported in this Thread, but unfortunately no fix possible/planned yet.
I hope this will be only optional in the next version.

[ghisler(Author)]

This should work a bit better now - TC remembers where the cursor _should_ be, e.g. at the beginning or the end of the selection, although it's impossible to set it there...

[StatusQuo]

Much better - fixed in TC7 rc2.

[ghisler(Author)]

Well, I want to hear your opinion and that of other users here before I move this to the "fixed" forum. I'm now remembering the position where the user started the selection, and then select from there either to the beginning or the end of the command line. That's how the normal edit control does it. However, when the user then releases Ctrl+Shift, the cursor is always behind the selection because the cursor location cannot be set during the selection...

[StatusQuo]

No problem for me (at least today ).
Anyway, I would appreciate if this new control would be optional to prevent trouble in the future. How do you think about this?

[StatusQuo]

One new phenomenon, in the command line:
having text in the command line, press
- Home - to set the cursor to text beginning
- Shift-End - to mark all to the end of the text

Now:
- Shift-Cursor moves the right end of the selection (normal).
- Ctrl-Shift-Cursor moves the left end of the selection (unusual).

Is there maybe a way to make Ctrl-Shift-Cursor move the right end of the selection instead of the left?

[ghisler(Author)]

Ctrl-Shift-Cursor moves the left

No, that's not true! It moves the last moved side of the selected text, just like in the normal edit control. Try this: Place the cursor in the middle of the command line, then do Ctrl+Shift+Cursor to the left a few times, then to the right a few times, etc. The selection start will remain in the middle of the text where you started, while the selection end will move with the pressed keys.

[StatusQuo]

Ctrl-Shift-Cursor moves the left

No, that's not true!

I still think it is. Using your example I first got a little confused, because sometimes it worked, sometimes not.
I now think holding down (not releasing) the shift key has something to do with this:

Text in command line:

Code: Select all

word1_word2_word3

- place the cursor behind "word2"
- now press Shift key and don't release it until the end of this test
- press Ctrl-Shift-left (word 2 is selected)

- now Shift-right / Shift-left adds/deletes "_word3" to/from the selection,
- Ctrl-Shift-left / Ctrl-Shift-right adds/deletes "word1_" to/from the selection.

This only stops, when you are using Shift-left until the complete old seletion is gone (go more to the left side than the previous left end of the selection).

[ghisler(Author)]

Sorry, you can't mix Ctrl+Shift and Shift. Why? Ctrl+Shift always places the cursor at the end of the selection, it is IMPOSSIBLE to tell Windows to put the cursor at the beginning. So if you stick with Ctrl+Shift+Cursors, all will be fine, as well as when you use just Shift+Cursors. You cannot mix the two, though.

[StatusQuo]

Thanks for the explanation.
Combining these two is a basic thing from my view - I use Ctrl-key to fast get near the target position, then release it to do the fine positioning without Ctrl.
Workaround: marking only in direction left-to-right seems to avoid this problem.

Because the new one is not as easy to understand,
I would prefer to be able to optionally switch back to the old edit control. Is there a chance?

[StatusQuo]

2ghisler(Author)

Anyway, I would appreciate if this new control would be optional to prevent trouble in the future. How do you think about this?

As this still needs the workaround (last post) and new bug reports keep coming up on this: how about the idea of making this optional?
Then everybody could at least switch to the "old" version without this problem (like I would do).

In the CurrentPath-Editbox of TC 7.02a this is already switchable
as a (probably unwanted) side effect of the AutoComplete Setting:
http://ghisler.ch/board/viewtopic.php?p=133980#133980

[StatusQuo]

Now it's nearly 100% fixed:
In TC 7.03 there is an additional INI key in [Configuration]: CtrlArrow=0 brings back the standard windows behaviour (thanks very much for this).

Additionally, as I just found out, there's a workaround already since version 7.00: Alt+Ctrl+Shift+cursor_left (instead of Ctrl+Shift+cursor_left),
which seems to do the same temporarily whenever needed.

[ghisler(Author)]

Indeed my internal function reacts only to Ctrl and Ctrl+Shift modificators, it ignores any with Alt.

[StatusQuo]

Sorry, you can't mix Ctrl+Shift and Shift.

Update: this seems to be possible now in TC 7.5 (Beta 1).

A big thanks for that, I'll be switching back to the internal method (CtrlArrow=1).