NM_RETURN - Problem

[silentAMD]

Hi!
ich versuche mich gerade an nonvcl und stecke gerade fest: wenn ich eine datei in der listview öffnen möchte, funktioniert der doppelklick, aber wenn ich auf enter drücke, passiert NICHTS! der quelltext im anhang.

PLEASE HELP!!!


PS: super-respekt an luckie! ohne seine tutorials wäre ich nicht weit gekommen :wink:

[MathiasSimmack]

Du könntest es alternativ mal mit LVN_KEYDOWN probieren:

Delphi-Quellcode:

    WM_NOTIFY:
      case PNMHdr(lp)^.code of
        LVN_KEYDOWN:
          case PLVKeyDown(lp)^.wvKey of
            VK_RETURN:
              { ... }
          end;

Ein Beispiel für F2 findest du auch in den Tutorials (ms-help://Win32API.Delphi.20/CommonC/Listview/lv-0008.htm) und in der dazu gehörenden Demo. Und schau dir bei der Gelegenheit mal an, wie man die Trennung der WM_NOTIFY-Nachrichten besser machen kann:

Delphi-Quellcode:

    WM_NOTIFY:
      with PNMHdr(lp)^ do
        if(code = TTN_NEEDTEXT) then
        begin
          // Tooltipps für die Toolbar
        end;
        end
        else
        // ab hier der Code für die List-View
        if(hwndFrom = hLV) then
        begin
          { ... }
        end;

Normalerweise muss nämlich auch NM_RETURN funktionieren, nur weil du separat die Nachrichten für Tree-View und List-View bearbeitest, kommen sich da zwei Sachen u.U. in die Quere.

[silentAMD]

hi!

@MathiasSimmack: ich hab auch schon alles was mit der treeview zu tun hat aus wm_notify rausgschmissen, aber hat auch nicht geholfen.

ich hab auch schon in den tutorials von luckie (commonc/listview) den doppelclick um nm_return ergänzt und da funzt es!!! geht mal von meinem prog aus... :wink:

kann es damit zusammenhängen, dass ich die listview in einer resource ausgelegt habe? wenn ja wäre es für mich kein problem alles ohne resource zu machen, nur die buttons sehen dann so sch****e aus und lassen sich nicht wie normale buttons handeln.

[MathiasSimmack]

Ob Ressource oder nicht, das sollte eigentlich keine Rolle spielen. Die Programmierung unterscheidet sich ja auch nicht (sieht man mal vom Unterschied zwischen Dialog und Fenster ab ;)). Ich selbst habe zwar gerade kein Beispiel parat, in dem die List-View aus der Ressource kommt. Aber ich kann mir auch nicht vorstellen, dass es daran liegen soll.

Nur die List-View-Demo ist auch nicht ganz so kompliziert.
Sie ist ja nicht mit einem Programm aus dem praktischen Einsatz zu vergleichen. ;)
Also halten sich mögliche Fehlerquellen in Grenzen, und die Sache bleibt überschaubar.

[silentAMD]

Zitat:

Ich selbst habe zwar gerade kein Beispiel parat, in dem die List-View aus der Ressource kommt.

dann guck mal im anhang :mrgreen: :cyclops:


ich habe schon (fast) alles ausprobiert! schaut doch mal den anhang an und versucht es herauszubekommen! ich werd verrückt :wall: :wall: :wall: :wall: :wall:

[MathiasSimmack]

Ich meinte damit, ich habe gerade kein Programm von mir parat, in dem die LV aus den Ressourcen kommt. Dann hätte ich dir nämlich sagen können, ob es daran liegt. Aber wie gesagt: Ich glaube es nicht.

Ich schau mir bei Gelegenheit noch mal dein Programm an. Darf ich ein bisschen ändern, wenn ich was Änderungswertes finde? ;) Ich meine, Luckies Original-LV-Demo habe ich ja auch umgebaut. :mrgreen:

[silentAMD]

natürlich. ich habs ja deswegen zum download bereitgestellt...
versuchs... :zwinker: :mrgreen:

[silentAMD]

wenn du es schaffst, kannst du es dann wieder bereitstellen?

bitte!!! :cry:

[MathiasSimmack]

Na ja, versprechen werde ich nichts. Aber eins kann ich dir jetzt schon sagen: Du solltest mal über deinen Stil nachdenken. Bei so einem Ding hier

Delphi-Quellcode:

function dlgfunc(hDlg: hWnd; uMsg: dword; wp: wParam; lp: lParam): bool; stdcall;
var HitHandle: HTreeItem; tv: TTVItem; buf: array[0..MAX_PATH]of char;
rc: TRect; i: Integer;
const SB_SIMPLEID= $00FF; MINX = 500; MINY = 350;
  fCheckState: array[boolean]of cardinal = (0,MF_CHECKED);

sieht doch kein Mensch mehr durch. Oder war das der Versuch, meinen und Luckies Code so unkenntlich wie möglich zu machen, damit man nicht merkt woher du ihn hast? :mrgreen: Spricht was gegen:

Delphi-Quellcode:

function dlgfunc(hDlg: hWnd; uMsg: dword; wp: wParam; lp: lParam): bool;
  stdcall;
var
  HitHandle   : HTreeItem;
  tv          : TTVItem;
  buf         : array[0..MAX_PATH]of char;
  rc          : TRect;
  i           : Integer;
const
  SB_SIMPLEID = $00FF;
  MINX        = 500;
  MINY        = 350;
  fCheckState : array[boolean]of cardinal = (0,MF_CHECKED);

Klar, das belegt mehr Zeilen. Aber auf dein Programm hat das keinen Einfluss. Und es sieht übersichtlicher aus. Also: Eine vernünftige Gliederung und ab und zu mal eine Leerzeile schadet nicht. Im Gegenteil ... ;)

Schön ist auch, wenn du dir den rechten Rand von 80 Zeichen anzeigen lässt und diesen nach Möglichkeit nicht überschreitest. Wenn doch mal jemand den Quellcode ausdruckt, dann hat er keine Probleme.

[MathiasSimmack]

Tja, hätte ich nicht gedacht, aber im Dialog geht es nicht. Ich habe die Fenster und Controls mal via API erzeugt, und siehe da: Enter geht ... Merkwürdig. :gruebel:
Der Sache sollte man vielleicht mal auf den Grund gehen, denn ich wüsste nicht, was bei einer List-View, die aus einem Dialog kommt, anders sein soll als bei einer API-erzeugten. Na ja, im Anhang mal ein Quellcode, den ich persönlich als übersichtlich und lesbar einschätzen würde. :)

[silentAMD]

@MathiasSimmack: VIELEN VIELEN DANK :hello: :hello: :hello: :party: :balloon:
Dass du dir so viel Arbeit machst: RESPEKT!!!! :hello:

[silentAMD]

ach ja noch was: jetzt wo es mit resourcen tabu ist, wie bekommt man die buttons so hin, wie von einer resource??? die "normal" erstellten funktionieren nämlich nicht so recht (DEFPUSHBUTTON kann man mit enter betätigen, da er den focus hat) und sehen besch****n aus :kotz:

[MathiasSimmack]

Mal seh´n ob du noch jubelst, wenn meine Rechnung bei dir eintrifft. :mrgreen:

[MathiasSimmack]

Zitat:

Zitat von silentAMD

ach ja noch was: jetzt wo es mit resourcen tabu ist, wie bekommt man die buttons so hin, wie von einer resource??? die "normal" erstellten funktionieren nämlich nicht so recht (DEFPUSHBUTTON kann man mit enter betätigen, da er den focus hat) und sehen besch****n aus :kotz:

Wo kommt denn da ein Button vor? Bzw. wo soll denn einer hin?
Wenn du ein Options- o.ä. Fenster benötigst, dann spricht nichts dagegen, das als Ressource zu gestalten. So mache ich´s ja auch. Ich programmiere das Hauptfenster bzw. die Controls (List-View, Tree-View, was auch immer) per API. Wenn ich dann aber einen Eintrag anklicke, dann erscheint ein Dialog. Und das ist ´ne Ressource. Nimm als Beispiel die Registry-Demo aus den Tutorials.

[silentAMD]

Zitat:

Wo kommt denn da ein Button vor? Bzw. wo soll denn einer hin?

naja, wenn du mein prog kennst (ArchivROM-Viewer in VCL), wirst du sicherlich die suchfunktion bemerkt haben. da ist ja ein button. und jetzt versuche ich alles auf API umzuschreiben :coder:

Zitat:

Oder war das der Versuch, meinen und Luckies Code so unkenntlich wie möglich zu machen, damit man nicht merkt woher du ihn hast?

... naja, mit etwas hilfe der Win32-API-Tutorials, die sehr gelungen sind!!! :mrgreen: :thuimb:
und ich persönlich habe programmieren mit vcl meistens durch code-beispiele und weniger durch theorie (verstehen) gelernt. wenn man den code dann bearbeiten möchte, lernt man anhand von fehlern super dazu! (ein buch hätte mich nicht auf denkfehler hinweisen können :wink: )

[MathiasSimmack]

Zitat:

Zitat von silentAMD

naja, wenn du mein prog kennst (ArchivROM-Viewer in VCL), wirst du sicherlich die suchfunktion bemerkt haben.

Ach so ... :oops: ... nee, kenne ich nicht.

Zitat:

und ich persönlich habe programmieren mit vcl meistens durch code-beispiele und weniger durch theorie (verstehen) gelernt.

Ja, das stimmt schon ... Und ich kann mich bspw. an Beiträge wie "Die 1024 Bytes des Monats erinnern". Das war in der alten DOS International (PC MAGAZIN). Da haben Programmierer ihre Programme "vergewaltigt" und alles in eine Zeile gequetscht, nur beim Quellcode unter den geforderten 1024 Bytes zu bleiben. Okay, das war witzig, aber kein Mensch hat durchgesehen. Darum habe ich dann irgendwann begonnen, den Code wieder lesbarer zu gestalten. Wobei ich aber zugeben muss, dass sich mein Stil im Laufe der Zeit auch mehrfach verändert hat.

Aber trotzdem habe ich mich immer bemüht, eine halbwegs lesbare Form beizubehalten. ;) Als Beispiel, was mir auch in ein paar älteren Quellcodes von -pieps- (Name zensiert! :mrgreen:) aufgefallen ist -

Ich deklariere Konstanten und Variablen usw. immer nur erst ab dem Zeitpunkt, ab dem ich sie brauche. Sprich:

Delphi-Quellcode:

const
  IDC_LISTVIEW = 1;
  IDC_BUTTON = 2;
var
  hLV,
  hButton : HWND;

function wndproc(wnd: HWND; uMsg: UINT; wp: WPARAM; lp: LPARAM): LRESULT;
  stdcall;
{ ... }

Benötige ich dann eine der Variablen doch mal vorher, dann übergebe ich sie meist per Konstante an die Funktion/Prozedur. Bei den o.g. Beispielkonstanten allerdings lasse ich mit mir reden und verschiebe sie auch mal weiter nach vorn, weil sich ihre Werte ja im Programm nicht ändern können.

Auf die Weise wundere ich mich nie, wenn irgendwas schief geht, weil sich an einer mir entfallenen Stelle im Quellcode vielleicht doch mal der Inhalt einer (globalen) Variable ändert. Weil: Das kann dann nicht passieren. :)

usw.

[Assarbad]

@silentAMD:
Nochmal (hatten wir schon in einem anderen ähnlichen Thread) - wie ist der Stil des Dialogs. Ach und noch was. Kannst du bitte die fragliche Ressource posten (in code-Tags). Danke!

@Mathias:

Zitat:

Zitat von MathiasSimmack

Ich deklariere Konstanten und Variablen usw. immer nur erst ab dem Zeitpunkt, ab dem ich sie brauche.

Pfui Ede ... also Geyer ... ähem Geier.
Das ist ja ein häßlicher Stil ;) ... wenn ich mir heute manchmal Programme von mir von vor 4 Jahren anschaue könnte ich auch ulfen - aber was soll's auf Änderungen habe ich auch keinen Bock mehr. Für Newbies muß das reichen.

Zitat:

Zitat von MathiasSimmack

Benötige ich dann eine der Variablen doch mal vorher, dann übergebe ich sie meist per Konstante an die Funktion/Prozedur. Bei den o.g. Beispielkonstanten allerdings lasse ich mit mir reden und verschiebe sie auch mal weiter nach vorn, weil sich ihre Werte ja im Programm nicht ändern können.

Das klingt sauber. Bei mir sind Konstanten oft in einer extra Include oder direkt hinter dem implementation Schlüsselwort.

[silentAMD]

@Assarbad: eigentlich erstelle ich nur eine listview und ein treeview:

Code:

        hTreeView := CreateWindowEx(WS_EX_CLIENTEDGE,
                                    WC_TREEVIEW,
                                    nil,
                                    WS_CHILD or WS_TABSTOP or WS_VISIBLE or
                                    TVS_HASLINES or TVS_LINESATROOT or TVS_HASBUTTONS or TVS_SHOWSELALWAYS,
                                    0,0,0,0,
                                    hwnd,
                                    HMENU(IDC_TREEVIEW),
                                    HInstance,
                                    nil);
                                    
        hListView := CreateWindowEx(WS_EX_CLIENTEDGE,
                                    WC_LISTVIEW,
                                    nil,
                                    WS_CHILD or WS_TABSTOP or WS_VISIBLE or
                                    LVS_REPORT or LVS_SHOWSELALWAYS or LVS_NOCOLUMNHEADER,
                                    0,0,0,0,
                                    hwnd,
                                    HMENU(IDC_LISTVIEW),
                                    HInstance,
                                    nil);

in der listview will ich nach einlesen der ordner in den treeview und der dateien ins listview diese dateien dann per return und doppelklick öffnen:

Code:

WM_NOTIFY:
      begin
      with PNMListView(lParam)^ do
        case hdr.code of
          NM_RETURN,
          NM_DBLCLK:
            OpenFile(hdr.hwndFrom);
        end;
      end;

// hier noch die procedure zum öffnen der dateien:

procedure OpenFile(const hLV: HWND; openwi: Boolean = FALSE);
var
  path: PChar;
begin
  if(ListView_GetSelectedCount(hLV) <> 1) then
    exit;

  path := PChar(GetPath(hTreeView,TreeView_GetSelection(hTreeView)));

  if not(FileExists(path + GetListItemText(hLV))) then
  begin
    ShowErrorMessage(hLV, GetLastError);
    exit;
  end;

  case openwi of
    TRUE: ShellExecute(hLV, nil, 'rundll32.exe', PChar('shell32.dll,OpenAs_RunDLL ' + path + GetListItemText(hLV)), nil, SW_NORMAL);
    FALSE: ShellExecute(hLV, nil, @GetListItemText(hLV)[1], nil, path, SW_NORMAL);
  end;

  if(GetLastError <> 0) and (GetLastError <> 1155) then
    ShowErrorMessage(hLV, GetLastError);

  if(GetLastError = 1155) and not openwi then
    if MessageBox(hLV, @(ShowErrorMessage(hLV, GetLastError, FALSE) + 'Möchten Sie manuell ein geeignetes Programm auswählen?')[1], ID_APP, MB_ICONQUESTION or 4) = IDYES then
      OpenFile(hLV, TRUE);
end;

wenn ich dies alles selbst erstelle (also ohne resource) dann klappt das öffnen wunderbar, nur fehlt dann die tab-funktion (nochmal danke an luckie für den hinweis... :oops: ). deshalb habe ich dank luckies tipp dies hier noch eingebaut, damit tab funktioniert:

Code:

  hwndMain := CreateWindow(PChar(MainWindowClass),
                         ID_APP,
                         WS_OVERLAPPEDWINDOW or WS_VISIBLE or WS_CLIPCHILDREN or WS_CLIPSIBLINGS,
                         GetSystemMetrics(SM_CXSCREEN) div 2 - ID_MINWIDTH div 2,
                         GetSystemMetrics(SM_CYSCREEN) div 2 - ID_MINHEIGHT div 2,
                         ID_MINWIDTH,
                         ID_MINHEIGHT,
                         0,
                         0,
                         HInstance,
                         nil);


while GetMessage(Msg, 0, 0, 0) do
    if not(IsDialogMessage(hwndMain, Msg)) then
      begin
        TranslateMessage(Msg);
        DispatchMessage(Msg);
      end;

und mit dieser funktion habe ich das gleiche problem wie wenn ich alles per resource erstelle (ist noch im anhang vom ersten post...)


und auf die frage, was ich für einen stil der dialog haben soll, weiß ich immernoch keine antwort... :wink: (eigentlich befindet sich ja der komplette code, eben nur mit resource, im anhang, aber kommt sowieso immer das gleiche problem...)


mfg

[Assarbad]

Also erstmal ist die Ressource komplett verkrüppelt. Du benutzt das gleiche Format wie ich in meinem uralten nonVCL-Tut. Wenn Luckie das (immernoch) verwendet, sollte er es schnellstens korrigieren. Das Format kennt nämlich nur der BRCC32.

Außerdem sind die Bemaßungen komplett krank. Das ListView ist größer als der ganze Dialog wenn man es in Visual-Studio lädt.

[Luckie]

Ich erstell meine Dialog Ressourcen noch mit dem VC6 Ressourcen Editor und damit wurden auch die im Tutorial erstellt.

[silentAMD]

welches format ist jetzt falsch das mit oder ohne resource bzw. wie soll man es sonst machen (ich halte mich an das tutorial von luckie...)???

[Assarbad]

Das ist auch gut so ... die dort im Anhang (erster Beitrag) sind, wurden IMO hangdgemacht. Die sind nicht kompatibel mit VS oder RC

Man sollte IMO immer den RC aus dem PSDK nehmen ... da hat man nie Probleme.

[Assarbad]

Scheiße ist der Code schlimm formatiert *brech* ... :-(

Tutorials hin oder her - man muß auch selber denken ...

Nebenbei: man bekommt das Programm garnicht zum Laufen, weil irgendwo eine Endlosschleife steckt :-(

[Assarbad]

Also ich ging davon aus, daß es an den Stilen entweder des Dialogs oder des ListView liegt. Dies scheint nicht der Fall zu sein. Sorry. Länger kann und will ich mich damit nicht beschäftigen.

Aber deinen Source solltest du überdenken, siehe Anhänge (ACHTUNG: ich habe einige Sachen auskommentiert, die du definitiv brauchst, nur für meine Tests. Woanders sind Kommentare.).

[silentAMD]

hi!

@Assarbad: sorry ich bin ja noch anfänger, aber ich will definitiv nicht auf vb umsteigen, weil dann jeder für meine anwendung die runtimes braucht.... und vorallem: danke dass du dir den quellcode angeguckt und einen kommentar zur besserung verfasst hast!! :thumb: thanks

ich habe jetzt noch die aktuelle version hochgeladen (jetzt mit icon), was da am anfang im anhang war, war uralt!


PLEASE HELP!!!

[Luckie]

Wenn du das Icon nicht mitlieferts, ist das Ressourcenskript nutzlos.

[silentAMD]

oops... :oops:

habs jetzt mit icon hochgeladen... :mrgreen:

[Assarbad]

Wow, das ist doch mal ein Unterschied. Der Code ist lesbarer geworden.

Was war jetzt das aktuelle Problem mit diesem Code?

[silentAMD]

@Assarbad: am problem hat sich nichts geändert: immernoch das NM_RETURN problem...

ich würde mich sehr freuen wenn es für beide (mit oder ohne resourcen) programmier-stile eine einheitliche lösung gibt, denn dann lohnt es sich für mich erst das ganze wieder zurück auf resourcen zu schreiben...


PLEASE HELP!!!

[silentAMD]

na? keine vorschläge?? :cry:

[Assarbad]

Nicht von mir, sorry.

[Dezipaitor]

hi

es scheint, dass das NM_RETURN Problem noch keiner gelöst hat?

Hier das Problem:

Das Problem ist, dass die Enter Taste, oder allgemein alle Tasten, im Dialog von einem ListView (oder anderen Elementen) nicht über die Nachricht WM_NOTIFY empfangen werden kann.

Dasselbe funktioniert jedoch, wenn man das ListView NICHT in einem Dialog hat.

Hier die Lösung :

Es liegt an IsDialogMessage, welche die eingehenden Nachrichten bearbeitet und bestimmte Tasten nicht an die Elemente (Listview) weitergibt. Die Tab-Taste wird dort z.B. verwendet, um zum nächsten Element zu springen.
Die Enter-Taste ist in Dialogen eine besondere Taste (genauso wie ESC), welche ein ID_OK repräsentiert. Also ein Klicken auf den OK-Button.
Daher empfängt kein anderes Steuerelement diese Tasten.

Es gibt drei Lösungen:

Wer IsDialogMessage selbst aufruft, der kann vorher einfach die Nachricht vorher schon abfangen,
und die Nachricht an das eigene Fenster schicken.

Delphi-Quellcode:

BOOL PreTranslateMessage(MSG* pMsg)
   {
      switch (pMsg->message)
      {
      case WM_KEYDOWN:
         {
            switch (pMsg->wParam)
            {
               case VK_RETURN:
               case VK_F5:
                  SendMessage(myWindowHandle, pMsg->message,pMsg->wParam,pMsg->lParam);
                  return FALSE;
            }
         }
      }
      
      return ::IsDialogMessage(m_hWnd, pMsg);
   }

(Sorry für C++ Code, aber es sollte klar werden.)


Die zweite Lösung ist, dass man von der Listview Klasse eine eigene Ableitung erstellt (Subclassing)
und dort die WindowProc überschreibt.
Es geht jedoch auch einfach so, dass man CreateWindow verwendet und in der Struktur, die WndProc
auf eine eigene Version setzt.

Das Ziel ist es dabei, die Nachricht WM_GETDLGCODE, die von IsDialogMessage an jedes einzelne Steuerelement
gesendet wird, abzufangen und einen besonderen Rückgabewert zu erzeugen:

GetDlgCode: http://msdn2.microsoft.com/en-us/library/ms645425.aspx
The Old new Thing Blog: http://blogs.msdn.com/oldnewthing/ar.../26/55872.aspx
MSDN sagt dazu: http://support.microsoft.com/kb/83302/de

Delphi-Quellcode:

LRESULT CALLBACK ListViewControlWndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
   {
      switch (message)
      {
      case WM_GETDLGCODE:
         switch (wParam)
         {
         case VK_F5:
         case VK_RETURN:
            return DLGC_WANTALLKEYS | DLGC_WANTMESSAGE;
         }
      }
      
         return ::DefWindowProc(hwnd, message, wParam, lParam);
}

Die dritte Lösung ist, die WindowProc eines existierenden ListViews zu verbiegen:

Delphi-Quellcode:

//Die Listview WindowProc verbiegen, damit man die Enter-Taste abfragen können,
//weil diese von IsDialogMessage verbogen wird
LPARAM wndProc = GetWindowLong(mListViewHandle GWL_WNDPROC);
SetWindowLong(mListViewHandle,GWLP_USERDATA,(LPARAM)wndProc);
SetWindowLong(mListViewHandle, GWL_WNDPROC,(LPARAM)&ListViewControlWndProc);

Delphi-Quellcode:

LRESULT CALLBACK ListViewControlWndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
   switch (message)
   {
   case WM_GETDLGCODE:
      switch (wParam)
      {
      case VK_F5:
      case VK_RETURN:
         return DLGC_WANTALLKEYS | DLGC_WANTMESSAGE;
      }
   }
   

        LPARAM l = ::GetWindowLong(hwnd,GWL_USERDATA);
   WNDPROC wndProc = (WNDPROC)l;

   if (wndProc)
     return wndProc(hwnd,message,wParam,lParam);
   
}

Wer Lust hat von den Mods kann den C++ Code nach Delphi portieren. Sorry aber ich hab grad kaum Zeit :D

[Dirk - nonVCL]

Hallo Dezipaitor,

Super Beitrag. Danke.

In Delphi habe ich das subclassing-Problem so gelöst:

Delphi-Quellcode:

type
  {Since Delphi does not distinguish between capital and non-capital
   letters, TWPARAM & TLPARAM should be declared.}
  TWPARAM = WPARAM;
  TLPARAM = LPARAM;

var
  WndProcLV : Integer;
  hListView : HWND;


//*************** LVWndProc ***************
function LVWndProc(handle : HWND; Msg : Cardinal; wParam1 : TWPARAM;
                   lParam1 : TLPARAM) : Integer; stdcall;

begin // LVWndProc
  // if "Return" was pressed, then process it in the list view
  if (Msg = WM_GETDLGCODE) and (wParam1 = VK_RETURN) then
  Result:= DLGC_WANTALLKEYS or DLGC_WANTMESSAGE
  // otherwise give the control back to the calling procedure
  else
  Result:= CallWindowProc(Pointer(WndProcLV), handle, Msg, wParam1, lParam1);
end; // LVWndProc
//*************** LVWndProc ***************



//begin main dialog function
//...

  hListView := GetDlgItem(hwndDlg, FolderList); // handle to the ListView
  hHeader   := SendMessage(hListView, LVM_GETHEADER, 0, 0); // LV header
  {Create a subclass for the list view,
   to catch the VK_RETURN for the list view}
  WndProcLV:= GetWindowLong(hListView, GWL_WNDPROC);
  SetWindowLong(hListView, GWL_USERDATA, WndProcLV);
  SetWindowLong(hListView, GWL_WNDPROC, Integer(@LVWndProc));

//...
// end main dialog function

Mit CallWindowProc muss man sich keine Gedanken um das richtige weiterleiten der Msg machen. Windows erledigt das. In meinen Programmen funktioniert das super.
Verbesserungen sind bestimmt noch möglich.

Viele Grüße

Dirk

[Dezipaitor]

hast du ausprobiert, ob du die Tab-Taste noch wie gewohnt verwenden kannst?

[Dirk - nonVCL]

Ja, kein Problem. Alle Tasten funktionieren wie sie sollen, inkl. TAB im Dialog (auch mit Return Taste).
Die Return-Taste wird nur abgefangen, wenn der der List View den Focus hat.