Comments on: Getting System Colors In C# http://www.masonmc.com/2008/getting-system-colors-in-c/ Mason's blog Fri, 05 Sep 2008 02:12:29 -0500 http://wordpress.org/?v=2.8 hourly 1 By: mason http://www.masonmc.com/2008/getting-system-colors-in-c/comment-page-1/#comment-20 mason Tue, 01 Jul 2008 23:28:35 +0000 http://www.masonmc.com/2008/getting-system-colors-in-c/#comment-20 You're absolutely right. After a bit of puzzlement over how I could have missed it, I realized what was going on - I recently uninstalled Visual Assist and moved onto a demo of ReSharper, and when it comes to Intellisense, and specifically the little drop-down list that appears after you type the last . on System.Drawing., ReSharper behaves differently than Visual Assist X. Using Visual Assist, if you type "Color," it shows you everything containing "Color." ReSharper shows you only things that start with "Color". So it showed only Color, ColorConverter, and ColorTranslator. I take back the comments about C# not calling them system colors, with apologies to C# for not giving it the benefit of the doubt - System.Drawing.SystemColors is logical and well organized. I'm still not completely comfortable with both being routed into KnownColor, though - seems like SystemColors should call into SystemInformation - but whatever, now I'm splitting hairs. Thanks for the comment - the lesson here is "don't trust your IDE (addons) exclusively, read the docs!" You’re absolutely right.

After a bit of puzzlement over how I could have missed it, I realized what was going on – I recently uninstalled Visual Assist and moved onto a demo of ReSharper, and when it comes to Intellisense, and specifically the little drop-down list that appears after you type the last . on System.Drawing., ReSharper behaves differently than Visual Assist X.

Using Visual Assist, if you type “Color,” it shows you everything containing “Color.” ReSharper shows you only things that start with “Color”. So it showed only Color, ColorConverter, and ColorTranslator.

I take back the comments about C# not calling them system colors, with apologies to C# for not giving it the benefit of the doubt – System.Drawing.SystemColors is logical and well organized. I’m still not completely comfortable with both being routed into KnownColor, though – seems like SystemColors should call into SystemInformation – but whatever, now I’m splitting hairs.

Thanks for the comment – the lesson here is “don’t trust your IDE (addons) exclusively, read the docs!”

]]> By: Steve http://www.masonmc.com/2008/getting-system-colors-in-c/comment-page-1/#comment-19 Steve Tue, 01 Jul 2008 10:46:25 +0000 http://www.masonmc.com/2008/getting-system-colors-in-c/#comment-19 I think you are not correct. The class System.Drawing.SystemColors is the class you're looking for. It's been part of the BCL since version 1.0 of the .NET Framework. No need to pinvoke GetSysColor anymore. Every color in System.Drawing.Color is implemented as a static Property which works as a simple wrapper to System.Drawing.KnownColor to simplify access to colors most frequently used. Instead of "Color.LemonChiffon" you can invoke "new Color(KnownColor.LemonChiffon)" with the former being far more practical. KnownColor is an enumeration (specifying LemonChiffon to return a value of 90) which makes it easier to interact with the Win32 subsystem. But you cannot access system colors with this structure which are hidden in the KnownColor enumeration for the reason just stated. The sealed SystemColor class makes use of KnownColor as well. For instance, you can call "SystemColor.ActiveBorder" to get the ActiveBorder system color or invoke "new Color(KnownColor.ActiveBorder)". I think the BCL is perfectly structured strictly following the fundamentals of encapsulation by isolating system colors and "normal colors" in two different data types which internally refer to KnownColor. Hope that cleared things up for you. Regards. Steve I think you are not correct. The class System.Drawing.SystemColors is the class you’re looking for. It’s been part of the BCL since version 1.0 of the .NET Framework. No need to pinvoke GetSysColor anymore.

Every color in System.Drawing.Color is implemented as a static Property which works as a simple wrapper to System.Drawing.KnownColor to simplify access to colors most frequently used. Instead of “Color.LemonChiffon” you can invoke “new Color(KnownColor.LemonChiffon)” with the former being far more practical. KnownColor is an enumeration (specifying LemonChiffon to return a value of 90) which makes it easier to interact with the Win32 subsystem. But you cannot access system colors with this structure which are hidden in the KnownColor enumeration for the reason just stated. The sealed SystemColor class makes use of KnownColor as well. For instance, you can call “SystemColor.ActiveBorder” to get the ActiveBorder system color or invoke “new Color(KnownColor.ActiveBorder)”.

I think the BCL is perfectly structured strictly following the fundamentals of encapsulation by isolating system colors and “normal colors” in two different data types which internally refer to KnownColor.

Hope that cleared things up for you. Regards.

Steve

]]>