App Compat Bug Explained: The Mysterious Black Background in Visual Basic 6 (VB6) Forms and Controls

Here is an issue I see pop up sporadically, so I figured I would spend the time to dissect how it happens: an application appears to work great on Windows XP, but when you run it on Windows 7 (or Windows Vista), it has a strange black background which used to be white. How does this happen?

Well, it’s not purely random – Windows just does what it is told, but I figured I would explain why we ended up with this.

First, let’s fire up Visual Basic 6 on Windows XP. Create a New / Standard EXE project. Form 1 pops up.


Now, let’s say we wanted to fiddle with the color of the background of that form. In Properties, go to BackColor, and then click the down arrow. Let’s say you like white, because it’s the new, modern color instead of that old Windows 2000 battleship gray, so pick the FIRST white color you see…

imageOh – my … looks like the FIRST white colored option I see, without having done anything special, is Active Title Bar Text. (That’ll always be white, right?) So, let’s pick that one.

And guess what happens? You have a form with a white background on Windows XP (with the default Luna theme), but suddenly has a black background on Windows 7. (If you’re using Windows 7, have a look at your title bar right now – unless you’ve fiddled with it, there is black text with a transparent background – blue if you don’t have DWM enabled.)

Here it is with the Luna theme:


Oh, and just so you don’t think it’s a Windows 7 or Windows Vista bug, let’s try it with the Silver theme on Windows XP:


And we’re doing precisely what the developer asked us to do – setting the form color as the Active Title Bar Text. But, if you look above, the developer probably didn’t ask us that intentionally – he or she probably just wanted white. It’s just that, inconveniently, they accidentally picked a system color since that’s what we show by default, and specifically selected a system color that tends to change rather a lot, and in a way that can render their form illegible.

Unfortunately, we don’t have a shim for this today, so if you are a victim of this, you can either change the code (the ideal mitigation) or, and I hesitate to say this, but you can change Active Title Bar Text. Having done this myself, I can vouch for the fact that it makes Windows look awful, and is a rather drastic step to fix an old app, but it’s an option (of last, last, last resort – please forget I even mentioned it). Or, you can just run it in XP Mode / MED-V / Citrix / etc.

Comments (3)

  1. Aaron Margosis says:

    I’ve seen customers insist that they need to continue to enforce the use of the "Windows Classic" theme because apps don’t work otherwise.  And typically this is the application bug that triggers it.  While it seems to reverting to Windows Classic fixes the bug, in truth the app probably violates other accessibility standards as well.  If it doesn’t work with XP’s Silver, or the Vista or Win7 defaults, it probably violates accessibility laws as well.

  2. dysos says:

    Though I’m afraid that developers working like you described, don’t read it:

    The correct way to set the color would be to set it either to white (if it has to be independent of the system color scheme and this is not a recommendation) or set it to "Window" (wich is what seems to be what is desired). "ControlLightLight" would be another candidate and allow even better adjustments by the user.

    I think that the source of this confusion is a flaw in the windows color scheme that doesn’t clearly distinguish "Window" applications like Texteditors and "Control" applications like database applications.

  3. Orange says:

    I have a way of fixing this for the VB apps that hit this without using a shim, and is actually pretty simple assuming you have an editor that handle opening the exe.