How do I post a screen shot?

WindowBlinds has caused this problem with InDesign and InCopy since version CS (October 2003). It doesn't happen to everyone, and not with all skins, but it does happen to majority of InDesign and WB users. Because that doesn't include Stardock, they ignore the problem.

Does it happen on all skins?

Technically, yes; it happens on ALL skins. The difference between those who notice it and those who don't are their choices of skins. You won't see the problem if the WB skin you use has dark-colored borders.

In this image you can see the problem in action. This is the Stroke palette. Other palettes also suffer the same "missing" text issue, but I chose this one to illustrate because it illustrates the full depth of the problem. Look closely. Not only is the pallete tab title missing, but so are the field labels and even the stroke preview itself (you should see a thick black rule in the first wide dropdown field).

I've seen several people complain about this issue, and I've suffered under it myself for quite some time. So, prompted by re-reading the above and Stardock's complete lack of response to anyone with this issue, I decided to figure out for myself what's causing this. Afterall, I'm an expert trained to troubleshoot and diagnose problems in InDesign, so I've got a headstart. I just had to learn how to use and interpret SkinStudio Pro (an application decidedly not built for right-brain creatives).

Quickly, here's how I discovered where the problem lay and how to fix it:

1. Opened InDesign with the problem manifesting, and took a screenshot of it with the PrntScrn button on your keyboard.

2. Opening that screenshot into Photoshop (paste into a new PSD document), I used the Eyedropper tool to find the RGB values of the seemingly missing palette title text (it was there, just the same color as the background).

3. Then, opening the current WB skin in SkinStudio and switching into SkinStudio's Code view, I looked for all instances of that RGB color. In my case, using the Noire skin, the color was 240,240,240--a light grey.

4. Finding four instances of RGB 240,240,240 used to color various parts of the skin, I changed them to 255,128,0 (bright orange), one at a time, saving and re-applying the skin between each change while also closing and re-launching InDesign.

Now, in this image, the results of my tinkering in the skin colors becomes obvious. Once found, I changed the color to 41,41,41, a near-black grey.

Ultimately, I found and solved the problem--for the current skin. I'll have to manually make the same change on every skin that has dark buttons and light button text.

All the colors in your WB skins are stored in the registry; they're a part of Windows all by itself. SkinStudio just provides access to them, and WB enables skins to alter those colors.

Other Windows applications like Photoshop get the color of their palette titles from the Menu Text color in the registry. InDesign, however, is getting that color from the Window Frame value. When a skin author sets the color of his Window Frame to be light, usually to match the color set for his Window Background value (and often the colors of the menubar buttons as well), then InDesign draws palette titles and palette and dialog descriptive text and field labels the same color as their backgrounds--those textual items seem to disappear.

Technically, the problem lies within InDesign. InDesign SHOULD pull the color of its user interface elements from the Menu Text value in the registry. In Adobe's defense, the InDesign programming team didn't (and still don't) notice a problem with doing that because, using Windows's theme and appearance controls, the Window Frame and other colors will always be correct. The Window Frame color is one of those not accessible via the Display Properties > Appearance tab; users can't alter it without editing the registry (directly or with the aid of an applet like WindowBlinds). It's only when WindowBlinds is added to the mix, and only with skins that use light-colored window frames and light colored window backgrounds, that the problem manifests. Because such a small minority of InDesign Windows users also use WB and such skins, Adobe likely has no idea the problem occurs.

So, while InDesign is technically at fault--a fact Stardock Support would be lightning quick to point out--the RESPONSIBILITY for resolving it lies with Stardock.

Adobe is the world's second largest software publisher while Stardock is a tiny little shareware company. Consequently, Stardock is much more agile than Adobe, and can more quickly and easily fix this issue (but they won't). Ideally, they would add into the WB per application menu a means of forcing the colors of Window Frame and Button Face to contrast. That would take a tiny bit of work, though, so they won't do it. What would be easier, but which they still won't do, is to fix the WindowBlinds ignore application override routine to finally and truly ignore applications. Currently, skin graphical elements are not applied to ignored applications, but skin-specified color schemes ARE.

The root cause of the problem with InDesign, WB, and roughly half the skins available for WB, is a tiny little poor choice on Adobe's part. But, Adobe is a large company, with a large list of issues prioritized mostly by the number of users with the problem. Not enough WB users exist to push a fix to the top of Adobe's list. And, of course, Stardock will say the same thing about InDesign users of their product. If Stardock DID care about the little guy, they'd proactively fix the problem they know Adobe will not. (Don't hold your breath.)

Here's how YOU can fix this issue on your own, without waiting for Stardock.

1. Download and install SkinStudio Pro through Stardock Central.
2. Once installed, load up SkinStudio Pro--you'll be prompted to choose file type associations, then you'll get a welcome screen. Close the welcome screen.
3. Choose File > Open Current WindowBlinds Skin.
4. In the center of the SkinStudio window, just above the graphical preview of the skin itself, click on the Code tab. Scroll down until you find the "[Colours]" section, which is often around line number 780.
5. Within that section, locate the line beginning with "WindowFrame=". The three sets of numbers after it are RGB color codes. Change that to a color that contrasts with the value of ButtonFace.

In RGB, color values run from 0, no color, to 255, full color. Because RGB respresents visible light, setting all three to no color--0,0,0--means no light, or black. By contrast, 255,255,255 is 100% of red, green, and blue--white. If ButtonFace is a set of low-valued RGB codes, then it's dark; set your WindowFrame color to a light or high RGB code value. Naturally, if ButtonFace is light, go dark on your WindowFrame color.

6. Once you've fixed the colors, save the skin and re-apply it. SkinStudio has a button on the buttonbar--but, in a stroke of user interface unfriendliness, apparently not a menu item--to re-apply the skin without opening WB's config screen or even closing the skin out of SkinStudio. Confirm your success in InDesign, exit SkinStudio, and get back to work in InDesign.

Hopefully the others whom I've seen from time to time complaining about experiencing this issue will find this thread.

The WB exclusion system works exactly as designed (and in fact the only way it can work). 

System wide colours are system wide so clearly its impossible to both exclude an app from WB (I.e. make WB do nothing to that app) and somehow make it use different system colours yet still use the skin colours system wide....

Based on your description, the problem will only happen if the skin author has manually changed those particular colours.

It would be wrong of WB to adjust those system wide colours based on your suggestion because it may well upset a different app that did things correctly.  The best we could possibly do would be to special case InDesign for that particular colour, and that may not be possible depending on how they obtain those colours.

SKOriginals: Yeah, that would do it, too. I haven't done much work in SkinStudio, so given that and the fact that I knew I was looking for a specific RGB color triplet, it was easier for me to hunt it down in code view than to figure out where system colors were located in that nested tree view on the left (which, for all I knew, could have been divided across multiple sections of the skin).

Neil: Makes sense. Although I think my suggestion for somehow forcing Window Frame and Button Face contrast is worth consideration. Alternatively, as software developers, Stardock may have a better chance at explaining the issue to Adobe's InDesign Dev team in Seattle in the proper terms, and getting the root of the issue resolved.

Another, but less savory, option would be if Stardock made the WinXP and Win Classic skins/themes part of the per app system. Within the WB UI, one can override the Display Properties settings by telling WB to apply Windows Classic or Windows XP Style, but those are not options for per application settings. Stick those in there, and then users can force apply to InDesign the colors InDesign's developers expected. Again, that's not the best way to resolve this issue but it is A way.

Bear in mind that the InDesign and InCopy programming team are also working on new products, including those that deal with Flash and HTML. It's entirely possible that their incorrect choice of places in the Registry from which to pull UI colors may make it into applications used by a larger percentage of, perhaps even a majority of, WB users. It would be behoove Stardock to pre-empt their own tech support nightmare by seeking a resolution now.

Stardock can easily see the problem for itself; just download the fully functional, 30-day try-n-die of InDesign CS2 from http://www.adobe.com/products/indesign/.

Bichur: "I like the 'only use this skin with this app' option" That's not a solution. You have the same problem if the skin you choose has a Window Frame color similar to the color set for Button Face--which is fairly often.