Listview Report-Style mit Header Control, wie Doppelklick auf Divider abfangen
-
Dann machst Du noch was anderes falsch. Leider bin ich kein Seher, kann daher nicht genauer werden.
-
Hier der Code vom gesubclasseten Listview der nicht läuft. In der Wndproc vom Hauptfenster, wird damit nach wie vor "HDN_DIVIDERDBLCLICK" erhalten. Info: ED(....) dient der Ausgabe in einem Editfeld.
/* =============================================================================== DialogSubclass_DlgListview2 =============================================================================== */ LRESULT CALLBACK DialogSubclass_DlgListview2(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam){ switch(message){ case WM_LBUTTONDBLCLK: ED("WM_LBUTTONDBLCLK\r\n", FALSE); // return 1; break; case WM_NOTIFY: switch(((LPNMHDR)lParam)->code){ case HDN_DIVIDERDBLCLICK: ED(va("HDN_DIVIDERDBLCLICK:\t%i\r\n", ((LPNMHEADER)lParam)->iItem), FALSE); // return FALSE; // return TRUE; break; default:{ break; } } break; default:{ break; } } return CallWindowProc(wProcListview2, hWnd, message, wParam, lParam); }
-
Das ist der Dialog Handler. Dort kommt der HDN_DIVIDERDBLCLICK auch nicht an.
Das Header Contorl ist ein Kind des List Controls, also kann es nur in der WndProc des List Controls ankommen, also ist ein Subclass notwendig.
-
Aber ich hab doch den Listview gesubclassed:
wProcListview2= (WNDPROC)SetWindowLongPtr(GetDlgItem(hWnd, DLG_LISTVIEW2), GWLP_WNDPROC, (LONG_PTR)DialogSubclass_DlgListview2);
-
OK. Den Namen der Prozedur habe ich anders verstanden...
Was sagt Spy++? Irgendwohin geht doch die Nachricht?
-
Deine (gekürzte) Fassung sieht in meinen Augen so aus:
JohnDoooe schrieb:
/* =============================================================================== DialogSubclass_DlgListview2 =============================================================================== */ LRESULT CALLBACK DialogSubclass_DlgListview2(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam){ switch(message){ case WM_NOTIFY: switch(((LPNMHDR)lParam)->code){ case HDN_DIVIDERDBLCLICK: break; } break; } return CallWindowProc(wProcListview2, hWnd, message, wParam, lParam); }
Du leitest die Notification also an das ListView weiter. Diese kommt auch tatsächlich dort an. It's Magic.
Was war nochmal das Problem?
-
Nein in meiner gesubclassten Wndproc des Listviews kommt sie nicht an, aber in der ebenfalls gesubclassten Wndproc des Dialobox-Parent-Fensters des Listviews läuft sie auf, aber dort wie bereits gesagt hat ein Return TRUE oder FALSE überhaupt keine Auswirkungen ob eine Weiterverarbeitung der Nachricht unterdrückt werden kann. Und gnau so steht es auch in der Doko zu HDN_DIVIDERDBLCLICK.
Daher wundert mich deine Aussage Mox, dass du die weitere Verarbeitung der Nachricht irgendwie beeinflussen kannst.
-
JohnDoooe schrieb:
Nein in meiner gesubclassten Wndproc des Listviews kommt sie nicht an,
Das heißt, Dein ListView reagiert ganz wunderbar auf HDN_DIVIDERDBLCLICK, ohne die Notification selbst jemals erhalten zu haben. Respekt.
Wie kommt man denn nun an ein Beispiel, dass das von Dir beschriebene Verhalten illustriert?
-
Ich bin nicht derjenige der behauptet hat, das Verhalten von HDN_DIVIDERDBLCLICK anhand eines Rückgabewertes beeinflussen zu können, wohlgemerkt entgegen der Aussage was in der Microsoft Doku zu HDN_DIVIDERDBLCLICK steht. Ich sagte lediglich, dass ich HDN_DIVIDERDBLCLICK nicht beeinflussen kann, und das HDN_DIVIDERDBLCLICK bei mir nicht in der Messageque des gesubclassten Eventhadlers des Listviews auftritt. In der Messageque des gesubclassten Elternfenster des Listview tritt HDN_DIVIDERDBLCLICK sehr wohl auf, warum auch immer. Ich habe auch erklärt wie ich geprüft habe dass das Fenster korrekt gesubclasst wurde, indem ich z.B. WM_LBUTTONDBLCLK abgefangen habe und dies dort korrekt angezeigt wurde wo es zu erwarten war.
Genau so komm ich zu einem Beispiel das dieses Verhalten illustriert.
-
JohnDoooe schrieb:
Genau so komm ich zu einem Beispiel das dieses Verhalten illustriert.
Wie schön für Dich. Dann behalte dieses Beispiel mal ganz allein für Dich. Ich brauche es ja nicht, denn auf meinen Rechnern funktioniert alles exakt so, wie es zu funktionieren hat. Und ja, das habe ich tatsächlich auch ausprobiert.
Eigentlich dachte ich, Du willst eine Lösung. Wie man sich doch täuschen kann...
-
So sieht übrigens mein Test aus:
static WNDPROC gs_wndpListView; LRESULT CALLBACK ListViewProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam) { switch(uMsg) { case WM_NOTIFY: if(reinterpret_cast<NMHDR*>(lParam)->code == HDN_DIVIDERDBLCLICK) return 0; default: break; } return CallWindowProc(gs_wndpListView, hWnd, uMsg, wParam, lParam); } INT_PTR CALLBACK DlgProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM) { switch(uMsg) { case WM_INITDIALOG: { HWND hWndLV = GetDlgItem(hWnd, 12345); RECT rc; GetClientRect(hWndLV, &rc); LVCOLUMN lvc = {}; lvc.mask = LVCF_FMT | LVCF_WIDTH | LVCF_TEXT; lvc.fmt = LVCFMT_LEFT; lvc.cx = (rc.right - rc.left - GetSystemMetrics(SM_CXVSCROLL)) / 3; lvc.pszText = TEXT("Spalte 3"); ListView_InsertColumn(hWndLV, 0, &lvc); lvc.pszText = TEXT("Spalte 2"); ListView_InsertColumn(hWndLV, 0, &lvc); lvc.pszText = TEXT("Spalte 1"); ListView_InsertColumn(hWndLV, 0, &lvc); gs_wndpListView = reinterpret_cast<WNDPROC>(SetWindowLongPtr(hWndLV, GWLP_WNDPROC, reinterpret_cast<LONG_PTR>(ListViewProc))); return TRUE; } case WM_COMMAND: switch(LOWORD(wParam)) { case IDOK: case IDCANCEL: EndDialog(hWnd, 0); return TRUE; default: break; } break; default: break; } return FALSE; } int WINAPI _tWinMain(HINSTANCE hInstance, HINSTANCE, LPTSTR, int) { static const BYTE s_bTemplate[] = { 0x01, 0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC8, 0x00, 0xC8, 0x80, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3C, 0x01, 0xB7, 0x00, 0x00, 0x00, 0x00, 0x00, 0x44, 0x00, 0x69, 0x00, 0x61, 0x00, 0x6C, 0x00, 0x6F, 0x00, 0x67, 0x00, 0x00, 0x00, 0x08, 0x00, 0x90, 0x01, 0x00, 0x01, 0x4D, 0x00, 0x53, 0x00, 0x20, 0x00, 0x53, 0x00, 0x68, 0x00, 0x65, 0x00, 0x6C, 0x00, 0x6C, 0x00, 0x20, 0x00, 0x44, 0x00, 0x6C, 0x00, 0x67, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x50, 0xCD, 0x00, 0xA2, 0x00, 0x32, 0x00, 0x0E, 0x00, 0x01, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x80, 0x00, 0x4F, 0x00, 0x4B, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x50, 0x03, 0x01, 0xA2, 0x00, 0x32, 0x00, 0x0E, 0x00, 0x02, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0x80, 0x00, 0x43, 0x00, 0x61, 0x00, 0x6E, 0x00, 0x63, 0x00, 0x65, 0x00, 0x6C, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x08, 0x81, 0x50, 0x07, 0x00, 0x07, 0x00, 0x2E, 0x01, 0x97, 0x00, 0x39, 0x30, 0x00, 0x00, 0x53, 0x00, 0x79, 0x00, 0x73, 0x00, 0x4C, 0x00, 0x69, 0x00, 0x73, 0x00, 0x74, 0x00, 0x56, 0x00, 0x69, 0x00, 0x65, 0x00, 0x77, 0x00, 0x33, 0x00, 0x32, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; INITCOMMONCONTROLSEX iccex; iccex.dwSize = sizeof(iccex); iccex.dwICC = ICC_LISTVIEW_CLASSES; InitCommonControlsEx(&iccex); DialogBoxIndirect(hInstance, reinterpret_cast<const DLGTEMPLATE*>(s_bTemplate), nullptr, DlgProc); return 0; }
-
Danke Mox, dass du dir die Mühe gemacht hast deinen Code zu posten.
Das Ergebiss überrascht mich nun sehr. Die Spalten werden kleiner und auch nicht. Wie kommt's. Ich hab deine Code in mein Projekt reinkopiert und den Rest meines Codes entfernt. Ergebniss Spalten verkleinern sich bei Doppelklick auf Divider.
Ich hab ein neues Projekt erstellt den Code reinkopiert, Ergebiss die Spaltengrösse bleibt bei Doppelklick unverändert.
Nach längerem Vergleich der Projekteinstellungen habe ich die eine Einstellung gefunden, die das Verhalten in die eine oder andere Richtung beeinflusst
"Allgemein->Zeichensatz" "Unicode-Zeichensatz" zeigt das von dir beschriebene Verhalten, "Multi-Byte-Zeichensatz verwenden" oder "nicht festgelegt" ruft das von mir beschriebene Verhalten hervor.
Seltsame Sache.
-
Ach so ist das. Dann reagiere mal in der SubclassProc sowohl auf HDN_DIVIDERDBLCLICKA als auch auf HDN_DIVIDERDBLCLICKW, damit sollte sich das Problem in Luft auflösen.
-
Ja jetzt geht's danke.