Hi,

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

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:

zusammenfalten · markieren

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:

markieren

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:

zusammenfalten · markieren

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

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

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

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

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.

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

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

Gruß
Neutral General

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.

Hi,

nein, nein das mit dem WM_PAINT stimmt nicht:

zusammenfalten · markieren

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?

du vergisst das da wohl noch die DefWndProc aufgerufen wird welche dann malt?!

Hi,

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