On Wednesday, 28 December 2016 11:47 PM, Nikolay Sivov wrote:
On 28.12.2016 14:47, Hugh McMaster wrote:
@@ -485,7 +494,7 @@ HWND CreateListView(HWND hwndParent, UINT id) /* Get the dimensions of the parent window's client area, and create the list view control. */ GetClientRect(hwndParent, &rcClient); hwndLV = CreateWindowExW(WS_EX_CLIENTEDGE, WC_LISTVIEWW, ListView, - WS_VISIBLE | WS_CHILD | WS_TABSTOP | LVS_REPORT | LVS_EDITLABELS, + WS_VISIBLE | WS_CHILD | WS_TABSTOP | LVS_REPORT, 0, 0, rcClient.right, rcClient.bottom, hwndParent, ULongToHandle(id), hInst, NULL); if (!hwndLV) return NULL;
Clean way to do that is to block edit operation using LVN_BEGINLABELEDIT notification. So basically you should always return TRUE from it, except for the case when edit is triggered with UI command, in this case you can temporarily enable edit, and block it back when done. But I'm curious, why do you want to do that in a first place, what's wrong with the ability to click-rename items?
Patch 1/2 prevents label renaming via left-click in regedit's treeview controls. (See also [1]). The same left-click to rename behaviour also occurs with regedit's ListView control, so I'm just extending the same solution to it, so we don't have different behaviour.
And as noted in [1], you can't click to rename in the Windows version of regedit.
I thought of using LVN_BEGINLABELEDIT to handle the edit behaviour, but I'm not sure how to determine whether the command was sent from the UI via WM_COMMAND or directly from the ListView click via WM_NOTIFY.