the source code for
ColorToRGB is:
function ColorToRGB(Color: TColor): Longint;
var
i: integer;
begin
i := SysColorToSysColorIndex(Color);
if i <> -1 then
Result := GetSysColor(i)
else
Result := Color;
Result := Result and $FFFFFF;
end;
if the parent's colour is
clDefault, then
ColorToRGB returns 0x000000 - which strictly speaking should be black. attached is a test project, that contains a test panel and a test button, along with 3 buttons in a row to select the form's colour setting: clDefault, clBackground, clMoneyGreen. to display an item's
ColorToRGB result click on the item (the TPanel, the TButton, or any blank area of the TForm) and a popup message will appear.
the second number displayed in the popup is the result of
SysColorToSysColorIndex.
where else that may happen
at least with
InputDialog and
InputCombo, although i am sure there are other instances, but the thing is it is only visible under the right desktop theme. and even then, many folks would likely not even notice the slight shade difference if it was only minor. or not care - it is really a "style bug" from the user's perspective, like finding a message displayed that has a punctuation or spelling error.
The question is:
- is the panel only used for positioning, and otherwise waste of a window handle, because functionality and visibility wise the buttons should be part of the parent
Or
- is the panel part of the design, and if a colorscheme makes panels visible by changed color, then that panel is correctly shown according to scheme.
my experience - mostly with Linux in recent years - is that a TPanel by default has a beveled border, and that it has NO transparent property. just checked under winXP, and this holds true there too. if used with the default of a beveled border, it would make some aesthetic sense for a TPanel to be a slightly different colour to the form it was sitting on; under winXP there appears to be no colour difference. a TPanel can also respond to mouse clicks, and can indeed be used as a simple button. it can be moved forward in the Z-order and will then obscure other controls that happen to sit behind it. a TPanel can also be used to fix a ragged edge in a multi-line TLabel so that other surreounding controls line up correctly. i would describe it as one of the more versatile controls available
my feeling is that the
real bug lies in how
InputDialog et al have been implemented, where whoever coded these routines should have made sure that the TPanel being used there had its colour tightly
synchronized to that of the form it was placed upon. but then, if the development of Lazarus was done mostly on windows, perhaps nobody could 'visually' see the problem.
cheers,
rob :-)
Recent
