[DevExpress-HowTo] TcxListBox / TListBox flickerfrei

[neo4a]

Da auch die TcxListBox auf TListBox aufsetzt, "leidet" auch diese Komponente an extremen Flickern, insbesondere beim Resizen z.B. eines Formulars/Frames. Auch das Aktivieren des DoubleBufferings bringt keine Besserung (btw gibt es das Problem auch in C#).

Durch Überschreiben der Prozedur CreateParams() verschwindet dieser Effekt. Dazu ist noch nicht einmal das Ableiten in eine eigene Komponente nötig, wenn man per Interception vorgeht. Dazu wird deklariert:

Delphi-Quellcode:

  TcxListBox = class(cxListBox.TcxListBox)
  public
    procedure CreateParams (var Params: TCreateParams); override;
  end;

und implementiert:

Delphi-Quellcode:

procedure TcxListBox.CreateParams(var Params: TCreateParams);
begin
  inherited CreateParams(Params);
  Params.ExStyle := Params.ExStyle or WS_EX_COMPOSITED; // or WS_EX_LAYERED;
end;

Das auch manchmal vorgeschlagene Attribut WS_EX_LAYERED hat bei mir einen lustigen "Freistellungs"-Effekt der Listbox bewirkt und also nicht funktioniert.

Diesen Code kann man auch in eine separate Unit auslagern. Dann ist darauf zu achten, dass sie in der Uses-Klausel am besten als letzte Unit eingebunden wird. Das gilt auch, wenn man so die Standard-Listbox reparieren will.

HTH.

[Stevie]

Mithilfe der JCL kann man das auch ohne Einbinden der Unit an korrekter Position bewerkstelligen:

Delphi-Quellcode:

uses
  JclSysUtils;

type
  TListBoxFix = class(TCustomListBox)
  public
    procedure CreateParamsFix(var Params: TCreateParams);
  end;

procedure TListBoxFix.CreateParamsFix(var Params: TCreateParams);
begin
  inherited CreateParams(Params);
  Params.ExStyle := Params.ExStyle or WS_EX_COMPOSITED;
end;

procedure PatchVirtualMethod(AClass: TClass; OldMethod, NewMethod: Pointer);
var
  i: Integer;
begin
  for i := 0 to GetVirtualMethodCount(AClass) do
    if GetVirtualMethod(AClass, i) = OldMethod then
      SetVirtualMethod(AClass, i, NewMethod);
end;

initialization
  PatchVirtualMethod(TListBox, @TListBoxFix.CreateParams, @TListBoxFix.CreateParamsFix);
  PatchVirtualMethod(TcxInnerListBox, @TListBoxFix.CreateParams, @TListBoxFix.CreateParamsFix);

[neo4a]

Zitat von Stevie:

Mithilfe der JCL kann man das auch ohne Einbinden der Unit an korrekter Position bewerkstelligen:

Sehr cool. Gibt es da Einschränkungen vom Einsatzspektrum her?

[Stevie]

Theoretisch nicht. Du musst nur drauf achten, dass du in einem Fall wie oben noch eine Vererbungshierarchie hast, die einen "freien" Slot hat. Ansonsten musst du halt statt des inherited calls den Code aus der anderen Methode kopieren. In den neueren Delphi Versionen kannst du über class helper sogar auf private Member zugreifen - sehr nützlich, wenn du wie ebend erwähnt Code kopieren musst, der auf solche zugreift.

Ich verfolge diesen Ansatz schon eine Weile, um in DSharp diese leidigen Interceptor Klassen und die damit einhergehende zwingende Reihenfolge in der uses Klausel loszuwerden.

[neo4a]

Zitat von Stevie:

Theoretisch nicht. Du musst nur drauf achten, dass du in einem Fall wie oben noch eine Vererbungshierarchie hast, die einen "freien" Slot hat. Ansonsten musst du halt statt des inherited calls den Code aus der anderen Methode kopieren. In den neueren Delphi Versionen kannst du über class helper sogar auf private Member zugreifen - sehr nützlich, wenn du wie ebend erwähnt Code kopieren musst, der auf solche zugreift.

Dachte ich es mir doch, dass das mit dem inherited in Deinem Code nicht funktionieren kann, nicht wahr?

Zitat von Stevie:

Ich verfolge diesen Ansatz schon eine Weile, um in DSharp diese leidigen Interceptor Klassen und die damit einhergehende zwingende Reihenfolge in der uses Klausel loszuwerden.

Tja, so ändern sich die Zeiten: Noch vor nicht gar zu langer Zeit waren Class-Interceptoren so etwas von heißer Stoff...

Ansonsten habe ich mit dem Austausch/Umbiegen/Korrigieren von TcxCustomInnerListBox.NeedDrawFocusRect() noch einen schönen Anwendungsfall Deiner Lösung, um den dämlichen Fokus-Rect der Listbox loszuwerden. Derzeit funktioniert es nur, indem ich der InnerlistBox eine Fake-OnDrawItem-Prozedur zuweise. Und das ist, was ich ohne Umschweife, die sich manchmal aber gar nicht, wenn nicht sogar überhaupt nicht, verhindern lassen, zugebe, nicht sehr elegant.

[Stevie]

Zitat von neo4a:

Dachte ich es mir doch, dass das mit dem inherited in Deinem Code nicht funktionieren kann, nicht wahr?

Doch, weil ich TListBox patche und die hat keine eigene CreateParams. Die Fix Klasse ist von TCustomListBox abgeleitet, so dass der inherited Call die CreateParams von dort aufruft. Und dann stopfe ich die TListBoxFix.CreateParams in den "leeren" (er ist ja nicht leer, sondern weist auf TCustomListBox.CreateParams) TListBox.CreateParams Slot.

Also im Grunde ist das nix anderes als ein runtime override.

[neo4a]

Zitat von Stevie:

Zitat von neo4a:

Dachte ich es mir doch, dass das mit dem inherited in Deinem Code nicht funktionieren kann, nicht wahr?

Doch, weil ich TListBox patche und die hat keine eigene CreateParams. Die Fix Klasse ist von TCustomListBox abgeleitet, so dass der inherited Call die CreateParams von dort aufruft. Und dann stopfe ich die TListBoxFix.CreateParams in den "leeren" (er ist ja nicht leer, sondern weist auf TCustomListBox.CreateParams) TListBox.CreateParams Slot.

Also im Grunde ist das nix anderes als ein runtime override.

Gute Erklärung. Meine Bemerkung bezog sich darauf, dass das Patchen den Code in der ersetzten Methode praktisch radiert, inklusive inherited-Calls. Wenn ein solchermaßen gepatchter Code ein Update bekommt, dann braucht man wohl etwas Kaffee, BeyondCompare und einen guten Blick. (Sofern man sich an den Patch überhaupt noch erinnert, liegt er doch als Unit ohne Referenz irgendwo rum.)

[Stevie]

Zitat von neo4a:

Wenn ein solchermaßen gepatchter Code ein Update bekommt, dann braucht man wohl etwas Kaffee, BeyondCompare und einen guten Blick. (Sofern man sich an den Patch überhaupt noch erinnert, liegt er doch als Unit ohne Referenz irgendwo rum.)

"With great power..."