TC10.00/10.50b1+2: Buggy textbox shortcut behavior in button bar config dialog

[funkymonk]

TC10.00/10.50b1+2 x32 DarkMode @ Win10x64:

When changing a button bar (or just a single button) via RightClick->Change, the corresponding dialogs show very strange *and varying* behavior wrt a typical textbox shortcut:
In all textboxes (Command, Icon file, etc.) Ctrl+A sometimes
* simply puts the cursor at the end of the text
* simply deletes the entire text --> this is very annoying
* opens a dropdown list (in addition to the above)

Sometimes it really selects the entire text -- but that is rare.
Shouldn't Ctrl+A always select the entire text?

BTW: Ctrl+Left/Right/Backspace seem to work properly
And: Undo via Ctrl+Z in the current textbox would be great...

[AntonyD]

Yes, there is such incorrect behavior. Confirmed.
And there is 1000% chance of repetition - call the dialog of the button changing. Immediately by default, the cursor is placed in the first "Command" field and its value is fully selected. Press the CTRL+A buttons and this text selection is removed and the cursor jumps to the end of the text. Repeat pressing the CTRL+A buttons and all content of this field disappears.

And Support+++ for "Undo via Ctrl+Z in the current textbox would be great..."

[ghisler(Author)]

This seems to be caused by "Auto append suggested name". You can disable it in Configuration - Options - Operation.

Unfortunately this is entirely handled by Windows itself, so I cannot change it.

[funkymonk]

Unfortunately this is entirely handled by Windows itself, so I cannot change it.

This is bad news...

This seems to be caused by "Auto append suggested name". You can disable it in Configuration - Options - Operation.

Hm. AutoAppend is very convenient and I would like to keep it enabled.
Just to make a decision: To which textboxes does AutoAppend apply? If it is all textboxes in all dialogs in TC I would certainly keep it on...

[AntonyD]

This seems to be caused by "Auto append suggested name"

But doesn't this then mean - that this option should be removed from the settings altogether?
After all, it's only now that the behavior in all combo|edit boxes with history to filename has become logical and stable.
And with the mentioned option enabled, it was just the incomprehensible cases of behavior.
For what purpose was this option introduced in the first place? WHAT can it realistically do and WHERE can it do useful?

[ghisler(Author)]

But doesn't this then mean - that this option should be removed from the settings altogether?

Nope. Not everyone needs Ctrl+A in a single line edit box. Complain to Microsoft if it bothers you (good luck with that).

[AntonyD]

Not everyone needs Ctrl+A in a single line edit box

Again stop-stop - I don't' understand it. WHY the action "Select ALL" should not be used in ANY edit text controls?
I probably can't even remember now - how long the combination of these keys performs this function in any text controls in many WIN-programs.

Even in the editor of this post on the web form I can use this combination to quickly, for example, remove all text.
That is. I opened the post for editing, pressed these Ctrl+A keys - all the text was highlighted, and I deleted it by pressing another key - Del.
That's it. Fast, clear, stable. And so why these Ctrl+A keys are suddenly became unnecessary?

And how are these keys related to the mentioned option in the settings?
That's what I'm asking you to clarify. I don't understand - how these things relate to each other.
Auto-complementing something somewhere is clearly an additional function to something, not replacing something entirely!

[funkymonk]

I also find it strange to think that Crtl+A is not needed.
It is certainly useful for deleting the entire text or for copying/cutting it to the clipboard (Ctrl+C/V/X do actually work).
Apart, I also don't see the link between AutoAppend and ctrl+A in particular (especially since other ctrl shortcuts do work as expected).

On the other hand, if this is really an inherent problem of the MS control element I don't expect Mr. Ghisler to come up with a workaround.

[AntonyD]

On the other hand, if this is really an inherent problem of the MS control element

Do not see such problem with support of CTRL+A in all other programs which I have here...
And also do not see the problems, when in some editboxes auto appending/suggestion mechanism is starting to work when I start to type some paths elements, like C:\Progr....
Something not expected is happening imho in the subj in this current case...

[funkymonk]

On the other hand, if this is really an inherent problem of the MS control element

Do not see such problem with support of CTRL+A in all other programs which I have here...
And also do not see the problems, when in some editboxes auto appending/suggestion mechanism is starting to work when I start to type some paths elements, like C:\Progr....
Something not expected is happening imho in the subj in this current case...

I think exactly the same --- but since I don't know the sources I cannot really tell...

[ghisler(Author)]

I also find it strange to think that Crtl+A is not needed.

That's not what I wrote. My point is that auto-append breaks Ctrl+A, so the user can at least choose between auto-append and Ctrl+A in these controls. If I removed auto-append as AntonDudarenko suggested, then the user would not have that choice. Personally I prefer to keep auto-append in these controls, I can still use Shift+End or Shift+Home to select all characters. Of course I would prefer to support both Ctrl+A and auto-append at the same time. But auto-append is handled by Windows itself, I don't have any means to interfere.

[AntonyD]

There’s still some inconsistency between logic and current events.
IF ONLY Windows is responsible for supporting CTRL+A and AutoAppend combinations - then there should be no bugs or breaks in the work. Because This is done at a very deep level of the OS itself. Isn't it?
IF the code of the program is responsible for this support, then yes - maybe there is a bug somewhere that we can all reproduce and there is a place in code where we can find a bug and fix it. Sound's good, isn't it?

But now everything is being described in such a way that there is a glitch in supporting in all of this AND the OS itself = is the all that is responsible for it. It doesn't fit in my head.
I have just opened the easiest and built-in dialog "Save As" in the first program I came across. And in the field to enter the name(path+name) of the file to save began to type the path first - and yes, autocompletion immediately worked - I began to offer variants of paths. I went a little deeper into the selection and at the next stage of entering the symbol pressed CTRL+A - and everything worked as expected! There was a selection of everything I had previously printed/selected from the list of suggested ways... No deletions, cursor movements - nothing unusual and unexpected!
I.e. Both mechanisms have worked as they should, which is why they are both implemented at the system level. As I suspected in my first assumption.
And what happens in our case in the program under discussion? Here something works, but There something no longer works???

[ghisler(Author)]

Total Commander does tell Windows to support auto-append when the option is enabled, that's what's different from other dialogs. I don't have the sources of "Save as", so I cannot say what it is doing differently.

[AntonyD]

Total Commander does tell Windows to support auto-append when the option is enabled

with help of using:
a function called SHAutoComplete
or
AutoComplete functionality in a COM object called AutoComplete?

I mean - if you've used the first - now for test you can take the second (or vice versa) - and compare the overall behavior.
As for now I have a strong feeling that something wrong was done in Lazarus' base support for handling win32 common controls...

Hmmm. I found some interesting comment at the Microsoft open code (https://referencesource.microsoft.com/#system.windows.forms/winforms/Managed/System/WinForms/TextBox.cs):

/// Native "EDIT" control does not support "Select All" shorcut represented by Ctrl-A keys, when in multiline mode,
/// and historically Microsoft TextBox did not support it either.

very strange, isn't it?

P.S.
But isn't Lazarus code support this: PreTranslateMessage(MSG* pMsg) function?
Add for the parent form/window of all editboxes in this bar/dlg:
if (pMsg->message == WM_KEYDOWN && ((pMsg->wParam == 'A') && GetKeyState(VK_CONTROL) < 0))
and if the current wincontrol is with focus - and it's from the list of expected ones that should be available to handle this shortcut - then send this:
pWnd->SendMessage(EM_SETSEL, 0, -1);

This will mean that you leave the auto-completion support on the shoulders of the OS itself, and you do all the SELET_ALL support in your code so that it works guaranteed.

[ghisler(Author)]

But isn't Lazarus code support this: PreTranslateMessage(MSG* pMsg) function?

I could not find that, where would that be?

I tried multiple things to intercept Ctrl+A and handle myself, but it always resulted in the bad behaviour:
1. Set KeyPreview to true for the form, and handle Ctrl+A in FormKeyDown
2. In the edit box custom control, handle the WM_KEYDOWN message
3. Handle the OnKeyDown message of the edit box control