Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Win32/Win64 API (native code) (https://www.delphipraxis.net/17-win32-win64-api-native-code/)
-   -   Delphi WndProc Problem (https://www.delphipraxis.net/110540-wndproc-problem.html)

Neutral General 19. Mär 2008 16:50


WndProc Problem
 
Hi,

Es geht mal wieder um meine VCL. Also ich hatte es bisher so, das wenn ich sowas hatte:

Delphi-Quellcode:
TEdit = class(TControl);
Das zuerst das TEdit.WndProc die Nachrichten behandelt hat und dann TControl.WndProc und dann die eigentliche Standard-WndProc.

Dann ist mir eingefallen das, dass eigentlich unlogisch ist und man es so machen sollte:
Delphi-Quellcode:
procedure TEdit.WndProc(var Message: TMessage);
begin
  inherited WndProc(Message); // neu
  case Message.Msg of
    //
  end;
  // inherited WndProc(Message); alt
end;

procedure TControl.WndProc(var Message: TMessage);
begin
  Message.Result := DefProc(FHandle,Message.Msg,Message.WParam,Message.LParam); // neu
  case Message.Msg of
    //
  end;
 // Message.Result := DefProc(FHandle,Message.Msg,Message.WParam,Message.LParam); alt
end;
So wird erst die ursprüngliche DefProc procedure aufgerufen, dann die von TControl und dann die von TEdit, also vom Allgemeinsten zum Speziellsten. So müsste es logischer und vorallem auch richtiger sein.

Nun habe ich versucht selbst Readonly zu implementieren und zwar ohne EM_SETREADONLY. Also habe ich es so versucht:

Delphi-Quellcode:
procedure TEdit.WndProc(var Message: TMessage);
begin
  inherited WndProc(Message);
  case Message.Msg of
    WM_CHAR: begin
               if FReadOnly then
                 Message.Result := 1; // alles <> 0 blockiert die Msg.
             end;
  end;
end;
Das funktioniert aber nicht... Mache ich es andersrum, also das ich vom Speziellen WndProc zum allgemeinen gehe (also eigentlich falschrum?!) dann funktioniert es:

Delphi-Quellcode:
procedure TEdit.WndProc(var Message: TMessage);
begin
  case Message.Msg of
    WM_CHAR: begin
               if FReadOnly then
                 Message.Result := 1;
             end;
  end;
  inherited WndProc(Message);
end;

procedure TControl.WndProc(var Message: TMessage);
begin
  case Message.Msg of
    // uninteressant, WM_CHAR wird hier nicht behandelt
  end;
  if Message.Result = 0 then
    Message.Result := DefProc(FHandle,Message.Msg,Message.WParam,Message.LParam);
end;
Woran liegt das?

Gruß
Neutral General

sirius 19. Mär 2008 16:59

Re: WndProc Problem
 
Was für eine Frage :gruebel: Hast du doch solber schon beantwortet.
Na weil du die DefWindowProc des Edits ausfrufst, bevor du Result veränderst.

Neutral General 19. Mär 2008 17:03

Re: WndProc Problem
 
Hi,

Und wie soll ich es sonst machen? Und wie wäre die Erklärung für deine Antwort? Also warum ist das schlimm, das ich zuerst DefWindowProc des Edits aufrufe?

Gruß
Neutral General

SirThornberry 19. Mär 2008 17:12

Re: WndProc Problem
 
weil man eine Message eigentlich nur einmal abhandelt. Warum sollte TControl das ReadOnly interpretieren wenn im TEdit das ReadOnly am Ende ganz anders implementiert ist?! Man reicht ja nicht generell die Messages durch sondern nur die welche nicht behandelt wurden oder explizit nochmal vom Vorgänger behandelt werden sollen

sirius 19. Mär 2008 17:15

Re: WndProc Problem
 
Na weil die DefWindowProc den Buchstaben bereits in das Edit schreibt befor du auf FReadOnly reagieren kannst.
Wie du das beheben kannst ist (ich kenn ja dein Konzept nicht) eben die DefWindowProc generell ans Ende zu schieben.

Neutral General 19. Mär 2008 17:18

Re: WndProc Problem
 
Zitat:

Zitat von SirThornberry
weil man eine Message eigentlich nur einmal abhandelt. Warum sollte TControl das ReadOnly interpretieren wenn im TEdit das ReadOnly am Ende ganz anders implementiert ist?! Man reicht ja nicht generell die Messages durch sondern nur die welche nicht behandelt wurden oder explizit nochmal vom Vorgänger behandelt werden sollen

Ja schon klar. TControl hat ja auch kein ReadOnly implementiert...

Also ich stell mir das so vor:

Das DefWindowProc behandelt ja die allermeisten Messages soweit wie es nötig ist, damit das Programm funktioniert. Danach käme TControl. Da behandele ich zurzeit WM_PAINT und WM_COMMAND (OnClick; hat derzeit jedes meiner Controls).

Dann kommt die Message ins WndProc des Edits. Da wird dann nochmal WM_COMMAND fürs EN_CHANGE behandelt und eben WM_CHAR. :arrow: Fertig.

Soweit die Theorie. Aber es scheint nicht so ganz zu funktionieren.

Gruß
Neutral General

SirThornberry 19. Mär 2008 17:21

Re: WndProc Problem
 
Beispiel wm_paint.
Wenn du sie ans TControl gibst wird dieses gemalt wie eben ein TControl aussieht. Danach malst du das TEdit drüber. Das ist doch aber schwachsinn - wozu das TControl malen wenn es später übermalt wird? Und falls es doch notwendig ist das es von TControl gemalt wird so kümmert sich die ursprüngliche WndProc von TEdit bereits darum.

Neutral General 19. Mär 2008 17:30

Re: WndProc Problem
 
Hi,

nein, nein das mit dem WM_PAINT stimmt nicht:

Delphi-Quellcode:
TControl = class
protected
  procedure DoPaint; virtual;
end;

procedure TControl.DoPaint;
begin
  // <--- Leer
end;

procedure TControl.WndProc(var Message: TMessage);
begin
  case Message.Msg of
    WM_PAINT: begin
                if FVisible then
                  DoPaint;
              end;
  end;
end;
So ist das doch Ok oder nicht? :wiejetzt:

SirThornberry 19. Mär 2008 18:25

Re: WndProc Problem
 
du vergisst das da wohl noch die DefWndProc aufgerufen wird welche dann malt?!

Neutral General 19. Mär 2008 18:29

Re: WndProc Problem
 
Hi,

Ok.. Kann mir denn jetzt jemand erklären wie ichs machen sollte?


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:17 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz