Inplace Win32 listview editing is always canceled

I have a listview in small icon mode on a 开发者_开发问答modeless Win32 dialog with LVS_EDITLABELS set. Regardless of whether editing was begun by a mouse click or programmatically by calling ListView_LabelEdit() and regardless of whether ESC or RETURN was hit upon finishing editing, when LVN_ENDLABELEDIT notification is received pszText of NMLVDISPINFO is always NULL, thus indicating a canceled edit. Returning TRUE from this notification has no effect.

I have found KB article http://support.microsoft.com/kb/130691 which applies to a treeview. Even following advice found there and subclassing the edit control did not work.

I suspect the default dialog logic is eating RETURN away and canceling the edit and I have no idea how to prevent this.

LVN_ENDLABELEDIT works fine for me and returns correct text. The problem is that when you press RETURN or ESC dialog processes it as IDOK or IDCANCEL and closes the dialog cancelling edit label. So if you comment these lines of code you'll get the correct text:

if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
{
    EndDialog(hDlg, LOWORD(wParam));
    return (INT_PTR)TRUE;
}

Does it work the same for you? Of cource it's not a solution just a hint.

In your dialog message handler, you need to use:

COMMAND_HANDLER(IDCANCEL, 0, OnCancel)
COMMAND_HANDLER(IDOK, 0, OnOK)

otherwise you get the behaviour you observed. I have no idea why this is the case, but I suspect the edit label logic is using the same IDs as IDCANCEL and IDOK but is using a control defined notification code as per http://msdn.microsoft.com/en-us/library/ms647591%28VS.85%29.aspx.

Ok, thanks to all of you for contributing. After many hours of debugging it turned out to be a problem with a subclass code eating away all WM_NOTIFY and WM_COMMAND messages without ever delegating them to subclassed procedure. I am not using neither MFC nor ATL, but rather my own wrappers. Once I started delegating WM_COMMAND and WM_NOTIFY, it automatically started working as expected.

So, this was my own fault :( Still, +1 for all for trying.