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. :twisted:

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:

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:

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. :wink:

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. :shock:

[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. :roll:

[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.

[Luckie]

Zitat:

Zitat von MathiasSimmack

• 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.
  

• Nicht mehr. Mitlerweile ist noch was dazu gekommen.
  
  Zitat:

  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.

  ---

  Habe ich gerade die Tage geändert.
  
  Zitat:

  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.

  ---

  Ist das wirklich so schlimm?
  
  Zitat:

  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.

  ---

  Da kommt nichts mehr dazu. :wink:
  
  Zitat:

  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.

  ---

  Jupp. Aber die DB ist schon alt, sehr alt. Sie wurde ständig erweitert und verbessert (was nicht nicht unbedingt für den Code gilt :? )
  
  Zitat:

  Die Konstante "DATFILE" konnte ich übrigens auskommentieren, ohne dass das Auswirkungen gehabt hätte.

  ---

  Ups. Die hatte ich deklariert und habe sie dann in der Aufregung ganz vergessen zu benutzen. :oops:
  
  Zitat:

  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.

  ---

Ansichtssache.

Aber das ganze noch mal neu schreiben würde viel Arbeit bedeuten. Das einzigste, was ich eventuell machen werde ist es, den Quellcode komplett zu überarbeiten. Ein Anfang ist schon gemacht, ich habe alles mal sortiert. Das lag aber daran, dass der Code-Explorer von den GExperts die Prozeduren nur in alphabetischer Rehenfolge anzeigt, nicht wie sie im Code stehen. :(

[MathiasSimmack]

Zitat:

Zitat von Luckie

Ist das wirklich so schlimm?

Ich sagte doch: das ist meine persönliche Meinung!

Zitat:

Ansichtssache.

Auch hier: so würde ich das machen. :roll:

Zitat:

Aber das ganze noch mal neu schreiben würde viel Arbeit bedeuten. Das einzigste, was ich eventuell machen werde ist es, den Quellcode komplett zu überarbeiten.

Ja, das meinte ich ja auch. Und ich kann dir jetzt schon sagen, dass ich mit meiner Vermutung richtig lag: nach etwas grober Kosmetik deines Codes funktioniert die ENTER-Taste nun. :)

Die etwas feinere Kosmetik brachte eine Ersparnis von 5k ein. Als Anregung: das meiste kannst du beim Lesen und Schreiben der INI-Datei sparen, wenn du den Editfeldern des Dialogs "200" aufeinander folgende IDs gibst und die dazu passenden Namen in einem Array unterbringst. Dadurch reduzieren sich diese X Zeilen mit Lesen & Schreiben auf eine for-Schleife.

Willste haben? :wink:

[Luckie]

Zitat:

Zitat von MathiasSimmack

Willste haben? :wink:

Laß mal stecken. Ich mich hat gerade die Arbeitswut gepackt und ich will sie jetzt noch mal komplett neu schreiben. Alles was ich von dem alten Code übernehme, werden die Ressourcen sein.

Ich habe mir überlegt, dass ich das jetzt auch alles etwas objektorinetiert angehe. Also das mit den Einstellungenspiechern kommt in ein Objekt und das Lesen und Schreiben der Datendatei kommt auch in ein Objekt. Ich muß mir nur erst einen Entwurf machen über die Methoden, Eigenschaften usw.

In einer Woche dürfte dann das Flagschiff meiner Webseite genaralüberholt sein. Dann stelle ich es auch hier mal vor.

[MathiasSimmack]

Klingt, als fühlte sich da wer bei der Ehre gepackt. :mrgreen:

[Luckie]

Zitat:

Zitat von MathiasSimmack

Klingt, als fühlte sich da wer bei der Ehre gepackt. :mrgreen:

Dazu nur so viel: :roll: