I’m dealing with a lot of code that looks like this:
if (btnLeftDock.BackColor != SystemColors.ButtonFace)
{
btnLeftDock.BackColor = SystemColors.ButtonFace;
}
if (btnRightDock.BackColor != SystemColors.ButtonFace)
{
btnRightDock.BackColor = SystemColors.ButtonFace;
}
if (btnTopDock.BackColor != SystemColors.ButtonFace)
{
btnTopDock.BackColor = SystemColors.ButtonFace;
}
if (btnBottomDock.BackColor != SystemColors.ButtonFace)
{
btnBottomDock.BackColor = SystemColors.ButtonFace;
}
The only reason I can imagine to do this is that there is theoretically some winforms-specific overhead to setting control colors like this:
btnLeftDock.BackColor = SystemColors.ButtonFace;
btnRightDock.BackColor = SystemColors.ButtonFace;
btnTopDock.BackColor = SystemColors.ButtonFace;
btnBottomDock.BackColor = SystemColors.ButtonFace;
I think it’s much easier to read, and I can’t see any performance difference, but the original developer must have had some justification. (right?)
There is something special about the BackColor property, it is an ambient property. What that means is that if the property was never assigned then the BackColor of the control will be the same as the parent’s BackColor value.
That’s highly desirable, it provides automatic consistent background color values. If the parent changes its BackColor then all child controls change it too, to the same value. As long as they never assigned it themselves.
That might have paralyzed the original author a bit. But since he used system colors, the test shouldn’t be necessary. I think.