[TC 11.00b4] Right arrow not working when renaming a file

[ghisler(Author)]

If the plugins use WH_CALLWNDPROC and don't pass all messages on to Total Commander, then it will miss some key presses and will lose track of the cursor position...

[unter_officer]

2ghisler(Author)
These plugins have been around for a long time. But the problems started in the 3rd beta TC. Before that, there were no problems.
Probably something has changed in the TC code that causes a conflict.

[Fla$her]

it will miss some key presses and will lose track of the cursor position...

This doesn't explain why the newfound problem is only in the positions to the left of the first two characters.

The bug is reproduced even if you run an empty hook, which does nothing at all, but simply transfers control to the next one in the chain:

Code: Select all

LRESULT __stdcall CallWindowProcProc(int nCode, WPARAM wParam, LPARAM lParam)
{
    return CallNextHookEx(hCWPHookID, nCode, wParam, lParam);
}

...

if (!hCWPHookID)
    hCWPHookID = SetWindowsHookEx(WH_CALLWNDPROC, &CallWindowProcProc, 0, GetWindowThreadProcessId(TCWnd, NULL));

From the plugins side, there is nothing to fix here. And it's pointless to wait for a correction from TwinKey, the author has not been in touch for more than 6 years.

[ghisler(Author)]

The main change between beta 2 and 3 was to call SendMessageW instead of SendMessage on NT based systems for the functions EM_GETSEL, EM_SETSEL, and GetWindowTextW to get the control text. I'm also calling CharPrevW and CharNextW instead of CharPrev and AnsiNext to move the cursor. This is necessary to properly support Unicode characters.

Especially EM_GETSEL returns the position of the selection or cursor in Unicode characters. I can't see a reason how a simple CallNextHookEx could interfere here, there is no CallNextHookExW to my knowledge.

[Fla$her]

2ghisler(Author)
But you can test on the 32-bit version, right?

[ghisler(Author)]

Yes, I have now debugged it, and found something interesting: It's indeed happening only while TWinkey is running!
When it was running, GetWindowTextW was returning an empty string. This seems to be due to a bug in the length field: It should contain the size of the widechar array in characters, but it was sent the size in bytes. Strangely it had no effect when TWinkey wasn't running, then GetWindowTextW returned the string just fine. Changing the size parameter to the right value seems to have fixed the problem. There was no buffer overflow, the used buffer was 4096 wide char characters large. The error was introduced when converting from ANSI to Unicode functions.

[Fla$her]

Changing the size parameter to the right value seems to have fixed the problem.

This is good news. I believe this will fix the problem when using SetMessageAction in autorun. Or has it not been checked yet?

[ghisler(Author)]

It should fix that too, we will see soon...

[Fla$her]

Fixed in b5.

[unter_officer]

Fixed in TC 11.00 beta 5.
Thank you!