IsVisualStylesEnabled Revisited

Erik Porter and I had some discussion via IM concerning his latest entry (where he gave me credit).  I noticed that he wasn’t using LoadLibrary and GetProcAddress when checking whether Visual Styles were enabled.  I was sure that it was needed so that you would be sure that you were referencing the correct DLL that was being loaded in memory, but it turns out this was completely unnecessary and was purely a product of me converting code from C/C++ and Delphi.  One side effect though to doing it this way was that you could verify that that method was indeed within that DLL in the event that Microsoft decided to pull it or change it’s name in a future version of Windows.  I don’t really think that would happen, but figured I’d throw it in there nonetheless.  So, after some experimentation and verifying both versions of the code… here is an updated method that replaces the previous one (be sure to reference the previous code for all the additional supporting code).

Private Function IsVisualStylesEnabledRevisited() As Boolean
  Dim os As OperatingSystem = System.Environment.OSVersion
  If os.Platform = PlatformID.Win32NT AndAlso (((os.Version.Major = 5) And (os.Version.Minor >= 1)) Or (os.Version.Major > 5)) Then
    Dim version As New DLLVERSIONINFO
    version.cbSize = Len(version)
    If DllGetVersion(version) = 0 Then
      Return (version.dwMajorVersion > 5) AndAlso IsThemeActive() AndAlso IsAppThemed()
    End If
  End If
  Return False
End Function

Just remove the ‘Revisited’ portion of the method name.  This significantly reduces the amount of code needed and is a little more readable.  In addition, the number of P/Invoke calls is significantly reduced.  If VisualStyles is currently not available, only one call is necessary (DLLGetVersion).  The second two (IsThemeActive and IsAppThemed) are only called if the version of the comctl32.dll is greater than 5 (version 6 or greater).

On interesting point that someone brought up on Erik’s blog comments is when checking for the platform, his code wasn’t future safe as for the version information.  He’s since updated his code appropriately, however, he pointed out that it’s probably not ‘future safe’ when checking on a Windows 64 bit platform.  I, unfortunately, have no way to verify whether or not the 64 bit version of Windows in addition to using the .NET Framework would still report as being Win32NT.  I did do a bit of checking though and with the Beta 1 bits of Visual Basic Express Edition, there is no addition of 64 bit enumerators for Platform; so still not sure.  However, there was a surprise enum addition… Unix!?!?!?  I guess that Microsoft is playing nice in regards to Novell/Mono and other similar projects. ;-)