Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   TListView.Color Bug? (https://www.delphipraxis.net/211232-tlistview-color-bug.html)

BigAl 19. Aug 2022 09:54

TListView.Color Bug?
 
Hallo zusammen,

ich habe ein TListView in einer Applikation welche zu Laufzeit den Skin ändern kann. Damit das Teil nicht flackert habe ich StyleElements.seClient deaktiviert und setze den Hintergund mit "ListView.Color := StyleServices.GetSystemColor(clWindow);" manuell. Funktioniert beim Öffnen des Formulars hervorragend.

Nun versuche ich auf den Wechsel des Skins zu reagieren:
Delphi-Quellcode:
procedure TscrDiagnostic.WMStyleChanged(var Msg: TMessage);
begin
  inherited;
  lvJobs.Color := StyleServices.GetSystemColor(clWindow);
end;
Leider hat das keinen Effekt. In der VCL habe ich folgendes gefunden:
Delphi-Quellcode:
procedure TCustomListView.SetTextBkColor(Value: TColor);
begin
  ListView_SetTextBkColor(Handle, ColorToRGB(Color));
  ListView_SetBkColor(Handle, ColorToRGB(Color));
end;
Sollte da nicht "Value" zugewiesen werden? Ist das ein Bug?

Oder warum interessiert es das TListView nicht wenn ich die Farbe neu zuweise?

Any idea?

Alex

Uwe Raabe 19. Aug 2022 10:08

AW: TListView.Color Bug?
 
WM_STYLECHANGED ist von Windows und hat nichts mit dem VCL-Styling zu tun. Versuch es mal mit CM_STYLECHANGED.

BigAl 19. Aug 2022 10:17

AW: TListView.Color Bug?
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1510292)
WM_STYLECHANGED ist von Windows und hat nichts mit dem VCL-Styling zu tun. Versuch es mal mit CM_STYLECHANGED.

Oups. Ja, vertippt. Aber gehen tut es trotzdem nicht.

Die ListView nimmt die Farbe beim ersten mal (wenn das Formular erzeugt wird) an, dann immer irgendwie einmal verzögert. Beim Umschalten auf den System Style (Windows) geht es immer. Beim Umschalten auf einen anderen Style bleibt die Farbe des vorhergehenden Styles erhalten (Windows -> Style A = Windows, Style A -> Style B = Style A usw.). Invalidates, Repaint, Updates... Hilft alles nichts. Weird,...

Beim setzen der Farbe (ListView.Color := ...) stimmt die Farbe von der ListView noch. Später steht da wieder die alte Farbe (des vorherigen Styles) drin.

Uwe Raabe 19. Aug 2022 10:20

AW: TListView.Color Bug?
 
Kannst du ein Minimalbeispiel machen?

BigAl 19. Aug 2022 10:35

AW: TListView.Color Bug?
 
Zitat:

Zitat von Uwe Raabe (Beitrag 1510295)
Kannst du ein Minimalbeispiel machen?

Habe ich gerade versucht. Da funktioniert es allerdings. Ich muss dazu sagen, dass es sich bei der Form um eine eingebettete Form handelt. Diese hat als Owner und als Parent die Hauptform. Vermutlich bügelt das Hauptformular später nochmal drüber. Muss ich mal verfolgen. Melde mich wieder...

BigAl 19. Aug 2022 10:51

AW: TListView.Color Bug?
 
Ich habe die Zuweisung der Farbe jetzt im OnShow des Formulars. Da geht es.

Das CM_STYLECHANGED ist irgendwie zu früh. Müsste mal genau suchen wo die Farbe wieder zurück geändert wird. Das ist aber in den Tiefen der VCL nicht so trivial...

Uwe Raabe 19. Aug 2022 11:03

AW: TListView.Color Bug?
 
Zitat:

Zitat von BigAl (Beitrag 1510291)
Sollte da nicht "Value" zugewiesen werden? Ist das ein Bug?

Jein. Prinzipiell ist es zwar falsch, aber
Delphi-Quellcode:
SetTextBkColor
ist private und wird nur mit
Delphi-Quellcode:
Color
als Parameter aufgerufen. Daher wird es schwierig werden, dafür einen fehlschlagenden Test zu schreiben.

himitsu 20. Aug 2022 12:15

AW: TListView.Color Bug?
 
Jupp, WM_STYLECHANGED gehört zu SetWindowLong für GWL_STYLE und GWL_EXSTYLE.

Was im Windows den Delphi-Styles ähnlich kommt, sind die Themes, also eher WM_THEMECHANGED, aber da VCL-Style eher was Eigenes ist, hilft es diesbezüglich nicht.
Diesbezüglich schaue man in die Winapi.UxTheme rein.

VCL-Style siehe Vcl.Themes und Vcl.Styles
dort mal nach Register und Notification umschauen (z.B. TStyleEngineNotification) und die "message" an Methoden dort,
oder eben da reinsehen, wo man den Style umschaltet, denn wenn/falls da was gemacht wird, dann findet man es da :zwinker:

Delphi-Quellcode:
procedure TStyleManager.SetStyle(Style: TCustomStyleServices);
...
begin
  ...
    for I := 0 to Screen.FormCount - 1 do
      if Screen.Forms[I].HandleAllocated then
        if IsWindowVisible(Screen.Forms[I].Handle) then
          PostMessage(Screen.Forms[I].Handle, CM_CUSTOMSTYLECHANGED, 0, 0)
        else
          SendMessage(Screen.Forms[I].Handle, CM_CUSTOMSTYLECHANGED, 0, 0);

Und natürlich kannst du auch die WndProc deiner Komponente und der Form überschreiben und schauen, welche Messages beim Ändern des Styles dort ankommen.

TApplicationEvents.OnMessage liefert nur PostMessage und PostThreadMessage. SendMessage wird direkt verarbeitet und nicht rausgegeben. (bissl blöd, denn siehe den Code da oben :wall:)
Dafür muß man die gewünschte Klasse hooken (z.B. indem man sich in WndProc reinhängt), oder einen globalen MessageHook registrieren.

BigAl 20. Aug 2022 13:39

AW: TListView.Color Bug?
 
Hallo himutsu,

danke für Deine ausführliche Antwort. Das hilft mir auf jeden Fall und ich werde da bei Gelegenheit nochmal forschen!

Mit den Styles hatte / habe ich noch Kämpfe an anderen Fronten. Z.B. sorge ich dafür, dass ActiveControl des Hauptformulars nil ist ehe ich den Style wechsle. Ansonsten gibt's manchmal Exceptions. Dann habe ich ein paar Styles die auch nicht so stabil sind wie andere (alle original Emba). Aber optisch finde ich sie halt schon recht cool...

TurboMagic 20. Aug 2022 18:17

AW: TListView.Color Bug?
 
Was bedeutet nicht so stabil? Abstürze oder Darstellungsfehler? Und die Exception wenn MainForm.ActiveControl nicht nil ist, hast du da Mal in QP nachgeschaut ob das schon erfasst ist? Falls nicht bitte erfassen und hier die Report Nummer melden, ich bin an dem Absturz auch interessiert.


Alle Zeitangaben in WEZ +1. Es ist jetzt 11:23 Uhr.
Seite 1 von 2  1 2      

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