Problem mit WM_NOTIFY beim Listview und Return

[Luckie]

Delphi-Quellcode:

    WM_NOTIFY:
    begin
      { Benachrichtigungs-Codes vom Listview behandeln }
      if PNMHdr(lParam).idFrom = IDC_LV then
      case PNMHdr(lParam)^.code of
        { Doppelklick auf Listview-Eintrag -> Kontakt-Dialog öffnen }
        NM_DBLCLK, NM_RETURN:
        begin
          { Sender = Listview }
          Sender := SNDR_LV;
          Caption := GetCaption(hDlg, IDC_LV);
          { keinen Eintrag dierekt angeklickt, GetCaption ist gescheitert }
          if Caption = '' then exit;
          { ansonsten Kontakt anzeigen }
          DialogBox(hInstance, MAKEINTRESOURCE(200), hDlg, @dlgContact);
        end;

Der obiger Code sollte eigentlich auch ausgeführt werden, wenn der Listview den Focus hat und man Return drückt. Tut es aber nicht. Der Doppelklick funktioniert aber.

Der Code stammt aus meiner AdressDB, die man sich auch mit Source von meiner Seite runterladen kann.

[oki]

keine Ahnung. Wenn Du gar nicht weiterkommst hilft vielleicht ein Umweg.
OnKeyDown nutzen, auf Enter prüfen und Code in einer ausgelagerten Methode aufrufen (die dann auch für nm_Dblclk nutzen).

Gruß oki

P.S. Mein Notmotto ist: Viele Wege führen nach Rom. Schick ist nicht alles.

[CalganX]

Wird nicht funktionieren, da das Programm und der Source nonVCL ist.
@Luckie: vielleicht trotzdem in WM_COMMAND schreiben!?

Chris

[janjan]

Geb doch einfach mal PNMHdr(lParam)^.code aus und kuck was da drin ist wenn du Enter drückst...

[Luckie]

Zitat von janjan:

Geb doch einfach mal PNMHdr(lParam)^.code aus und kuck was da drin ist wenn du Enter drückst...

Auf die Idee bein ich auch schon gekommen. Nur bekommt die Anwendung alle Nase lang WM_NOTIFY.

[Motzi]

Zitat von Luckie:

Nur bekommt die Anwendung alle Nase lang WM_NOTIFY.

Dann leg eine Log-Datei an in die jede WM_NOTIFY-Message eingetragen wird.. du kannst ja zwischendurch noch andere Einträge machn, damit dich dann besser orientieren kannst und die betreffende Message besser lokalisieren kannst..

[Luckie]

Das wäre eine Idee. Aber das amche ich erst, wenn Mathias Simmack auch nichts mehr einfällt.

Ich werde irre. In dem Demo aus meinen Tutorials geht es.

Jetzt wird es verrückt:

Delphi-Quellcode:

LVN_KEYDOWN:
          if(PLVKeyDown(lParam)^.wVKey = VK_F2) then
          begin
            { Sender = Listview }
          Sender := SNDR_LV;
          Caption := GetCaption(hDlg, IDC_LV);
          { keinen Eintrag dierekt angeklickt, GetCaption ist gescheitert }
          if Caption = '' then exit;
          { ansonsten Kontakt anzeigen }
          DialogBox(hInstance, MAKEINTRESOURCE(200), hDlg, @dlgContact);
          end;

Mit F2 geht es aber nicht mit VK_RETURN.

[MathiasSimmack]

Zitat:

Aber das amche ich erst, wenn Mathias Simmack auch nichts mehr einfällt.

Es geht auch mit ENTER; ich habe mal eben meinen HED (Hosts Editor) entsprechend angepasst:

Code:

    WM_NOTIFY:
      case PNMHdr(lp)^.code of
        LVN_KEYDOWN:
          case PLVKeyDown(lp)^.wvKey of
            VK_RETURN:
              SendMessage(wnd,WM_COMMAND,MAKEWPARAM(IDC_EDITENTRY,BN_CLICKED),0);
          end;
      end;

Keine Probleme. Ich drücke ENTER und der Bearbeiten-Dialog erscheint.
So, what?

[Luckie]

Ich habe es ausprobiert. Es geht definitiv nicht bei mir. Auch NM_RETURN geht nicht. Farg mich bitte nicht, warum nicht.

[MathiasSimmack]

Meine Vermutung ist, dass sich -durch deine ganzen Erweiterungen/Änderungen/usw.- Stellen im Programmcode befinden, die zwar keine Fehler verursachen, sich aber gegenseitig behindern. Eine andere Möglichkeit gibt es eigentlich nicht, denn wenn ich an meine Programme denke: HED, UIS und EFlagsEd verfügen auch über Listview, Toolbar und Statuszeile. Prinzipiell also die selben Elemente wie in deiner Datenbank, nur dass ich eben auch mit ENTER die Listview-Items aufrufen kann (bzw. den Dialog, der dann erscheinen soll).
Ich habe mir mal den Quellcode des Programms angesehen, und meine ehrliche Meinung ist: wenn du mal Zeit und Muße hast, dann solltest du es von Grund auf neu schreiben!

Dinge, die mir besonders aufgefallen sind:

• Du hast einen Dialog als Hauptfenster. In dem Dialog steckt aber nur die Listview, alles andere wird im Programm erzeugt. Ich hätte diesen Schritt übersprungen und Fenster und Listview auch gleich im Programm erstellt; also ohne Dialogressource.
• Der Quellcode ist für meinen Geschmack zu unübersichtlich. Du hast zwar räumliche Trennungen (durch mehrzeilige Kommentare), aber manchmal stecken Prozeduren in "Sparten", in denen sie, IMHO, eigentlich nichts zu suchen haben.
• Was mir ebenfalls nicht sonderlich gefällt (persönliche Meinung!), ist das Deklarieren von Variablen an zentraler Stelle. Das mache ich nur bei Texten (Konstanten), die man z.B. übersetzen können soll. Variablen deklariere ich erst dann, wenn sie gebraucht werden; die ganzen Fenster-Handles z.B. erst vor der "WndProc", usw.
  Benötige ich so ein Handle dann doch vor seiner Deklaration, dann übergebe ich es der Prozedur (die es braucht) als Parameter. Erst wenn ich das Handle in verschiedenen Prozeduren benötige, ziehe ich es weiter nach vorn.
• Schau dir mal bitte den Teil mit dem Dropdown-Menü für den "Drucken"-Button an. Solltest du mal einen Button davor einfügen, oder solltest du evtl. die Toolbar-Anpassung ausprobieren, bei der der Anwender entscheiden kann, welche Buttons er wo sehen will, dann erscheint das Menü unter Garantie unter dem falschen Button.
• Es gibt einige Optimierungsmöglichkeiten im Code. Als Beispiel sei das Umschalten der Listview-Ansicht (Icon, Report, Liste) genannt. Das ist immer das selbe. Eine Prozedur, aufgerufen mit dem gewünschten Stilattribut (wie im Tutorial), würde den Code verkürzen und die Exe auch wieder ein Stückchen kleiner machen.
• Die Konstante "DATFILE" konnte ich übrigens auskommentieren, ohne dass das Auswirkungen gehabt hätte.
• Na gut, die Namen von bestimmten Parametern würde ich nicht als Fehler ansehen. Ich persönlich (!) bevorzuge nur eben das "richtige" Casten und vermeide daher Variablennamen, die mit irgendwelchen Typen identisch sind (HWND, WPARAM, LPARAM, HBITMAP, ...) - obwohl letztlich auch bloß LONGINTS usw. hinter solchen Typen stecken.