Steema Issues Database

Note: This database is for bugs and wishes only. For technical support help, if you are a customer please visit our online forums;
otherwise you can use StackOverflow.
Before using this bug-tracker we recommend a look at this document, Steema Bug Fixing Policy.



Bug 473 - TCustomTeePanel.PanelCOlor returns wrong colors when using teetree
Summary: TCustomTeePanel.PanelCOlor returns wrong colors when using teetree
Status: RESOLVED FIXED
Alias: None
Product: VCL TeeChart
Classification: Unclassified
Component: Other Components (show other bugs)
Version: 131119
Hardware: PC Windows
: High major
Target Milestone: ---
Assignee: Steema Issue Manager
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-26 04:19 EST by h.hasenack
Modified: 2013-11-26 06:16 EST (History)
2 users (show)

See Also:
Chart Series: ---
Delphi / C++ Builder RAD IDE Version:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description h.hasenack 2013-11-26 04:19:12 EST 
In my teetree I want to use clWindow as background color, unfortunately due to anything other than clBtnFace is not translated into an RGB color, causing transparent colors to fill the rect (system colors are negative values causing the transparency). This off course does not clear the rect causes the tree not to be cleared when collapsing or expanding nodes. 

The solution is pretty simple, instead of the "Result=clBtnFace" test I use the ColorToIdent routine to check if the color is some native color identifier. It it is, the COlorToRGB routine is used as before.

The adjusted code in TeeProcs.pas code now looks like this: 

function TCustomTeePanel.PanelColor:TColor;
{$ifdef HH_PATCH_TEETREE} // this patch allows more than only clBtnFace to be used as system color
VAR sDummy:string;
{$endif}
begin
  {$IFDEF FMX}
  result:=Color;
  {$ELSE}

  if ParentColor and Assigned(Parent) then
     result:={$IFNDEF CLR}TControlAccess{$ENDIF}(Parent).Color
  else
     result:=Color;

  {$IFDEF LCL}
  if result=clDefault then
     result:=$F0F0F0; //??
  {$ELSE}
{$ifdef HH_PATCH_TEETREE} // this patch allows more than only clBtnFace to be used as system color
  if ColorToIdent(Result,sDummy) then
    result:=ColorToRGB(result)
{$else}
  if result=clBtnFace then
     result:=ColorToRGB(result)
{$endif}
  {$ENDIF}

  {$ENDIF}
end;
Comment 1 h.hasenack 2013-11-26 04:21:01 EST 
Teetree lacks using colors from the style manager. Unsure wheter this is a choice or something forgotten.
Comment 2 david berneda 2013-11-26 06:10:09 EST 
(In reply to h.hasenack from comment #1)
> Teetree lacks using colors from the style manager. Unsure wheter this is a
> choice or something forgotten.

I guess its forgotten, we'd like very much to support both VCL and FMX Style / Theme colors and settings, but never had decided how to do it.

If possible, can you attach a test project using themes / styles that can reproduce the problem?  The big decision I think is which style items should be considered for which elements of TTree (and TChart).
Comment 3 david berneda 2013-11-26 06:16:14 EST 
(In reply to h.hasenack from comment #0)
> In my teetree I want to use clWindow as background color, unfortunately due
> to anything other than clBtnFace is not translated into an RGB color,
> causing transparent colors to fill the rect (system colors are negative
> values causing the transparency). This off course does not clear the rect
> causes the tree not to be cleared when collapsing or expanding nodes. 
> 
> The solution is pretty simple, instead of the "Result=clBtnFace" test I use
> the ColorToIdent routine to check if the color is some native color
> identifier. It it is, the COlorToRGB routine is used as before.
> 
> The adjusted code in TeeProcs.pas code now looks like this: 
> 
> function TCustomTeePanel.PanelColor:TColor;
> {$ifdef HH_PATCH_TEETREE} // this patch allows more than only clBtnFace to
> be used as system color
> VAR sDummy:string;
> {$endif}
> begin
>   {$IFDEF FMX}
>   result:=Color;
>   {$ELSE}
> 
>   if ParentColor and Assigned(Parent) then
>      result:={$IFNDEF CLR}TControlAccess{$ENDIF}(Parent).Color
>   else
>      result:=Color;
> 
>   {$IFDEF LCL}
>   if result=clDefault then
>      result:=$F0F0F0; //??
>   {$ELSE}
> {$ifdef HH_PATCH_TEETREE} // this patch allows more than only clBtnFace to
> be used as system color
>   if ColorToIdent(Result,sDummy) then
>     result:=ColorToRGB(result)
> {$else}
>   if result=clBtnFace then
>      result:=ColorToRGB(result)
> {$endif}
>   {$ENDIF}
> 
>   {$ENDIF}
> end;

This problem has already been fixed. It should be included in next update, and  earlier at our soon-to-be-released "nightly" builds.

More info here: 

http://www.teechart.net/support/viewtopic.php?f=3&t=14509&p=63969

I choose a different approach than using ColorToIdent (see below). Its more "hardcoded" but it runs faster.



  // This fix is for GDI+ only, that cannot accept the "fake" VCL 4 byte colors
  // defined in Graphics.pas (the System colors like clWindow, clHighLight, etc)

  if result=clNone then
     result:=clBlack
  else
  if (Cardinal(result)>={$IFDEF D7}clSystemColor{$ELSE}$80000000{$ENDIF}) and
     (Cardinal({$IFDEF D6}clMenuBar{$ELSE}clInfoBk{$ENDIF})>=Cardinal(result)) then
     result:=ColorToRGB(result)