by Kevin Ragsdale

Stop The Bleeding!

Have you ever noticed that some controls tend to “bleed” when the user clicks on them more than once?

Have you ever noticed that some controls tend to “bleed” when the user clicks on them more than once? I’ve seen it often with OptionGroups and Checkboxes when the BackStyle has been set to transparent.

Multiple clicks cause pixel bleeding

Multiple clicks cause pixel bleeding

The easiest “fix” I’ve found for this (besides making the BackStyle Opaque) is to put the following line of code in a user-actionable event (I usually put it in the Click or InteractiveChange event):

This.Caption = This.Caption

This code doesn’t actually do anything, but I have found that it “stops the bleeding”.

 

by Kevin Ragsdale

Paint It (Almost) Black

Got a label control you want to be black, all the time? Then paint it (almost) black.

In a previous post, I showed an ugly form. Ugly, because it looked awful when I ran the form with the Windows High Contrast Theme.

With the High Contrast Theme, normal black text appears yellow. Which is no problem at all when the text is drawn on a black background. But in my form, the text was drawn over a white shape control, and looked like this (the red arrows point to the yellow text):

Yellow text on a white background

Normal black text turns yellow in High Contrast #1 Theme.

So now I have a form that is unreadable in High Contrast. What I want to do is force Windows to draw the text black (since it is drawn over the white background).

 

There’s An Easy Fix For That!

This is simple to do. I set the ForeColor of the labels that I want to appear as black to RGB(2,2,2). This color change from RGB(0,0,0) is imperceptible to the human eye (it still looks black), but Windows sees it as an absolute color. And since I have changed it to something other than the default, Windows will display the label in my “near-black” color (since it is not the “Default”).

After my session at Southwest Fox, a couple of people said they do the same thing I do to force a label to be black, but they use RGB(1,1,1). Not sure why I picked 2,2,2 – but they’re both “black” to the naked eye — and either setting works fine.

Here’s an example of an instance of my “near-black” label on a form (the top label ForeColor is RGB(0,0,0) – the Default), while the label inside the white shape has a ForeColor of RGB(2,2,2) – or, as I like to call it, “forced black”:

Two labels, two different ForeColors, same effect.

Two labels, two different ForeColors, same effect.

And the same form, this time running in Windows High Contrast Theme:

The "near-black" label stays black

The “near-black” label stays black.

Later in the series, we’ll look at creating sub-classes for different controls. This one I’ll call the lblForceBlack control, subclassed from a base Label class.

by Kevin Ragsdale

Is Your App DPI-Aware?

When you tell Windows Vista (and 7 & 8) that your app is DPI-aware, Windows will not use DPI virtualization for your app and will no longer “lie” when you ask about the DPI settings.

Please note that by telling Windows that your app is DPI-aware, it is completely up to your app (you) to resize your UI in order to match user expectations based on their settings.

There are 2 different ways to tell Windows Vista, 7 and 8 that your app is DPI-aware:

  • a Windows API function, or
  • adding a section to your apps manifest file.

Using a Windows API Function

Windows Vista, 7 and 8 contain an API function named SetProcessDPIAware. The function has no parameters. It returns a zero if the function fails, and a non-zero result if the function succeeds.

Using it from within Visual FoxPro is easy:

DECLARE INTEGER SetProcessDPIAware IN WIN32API
SetProcessDPIAware()

The function simply tells Windows, “This app (process) is DPI Aware, so please do not lie to me. I will handle all of the resizing myself, so my users will see things the way they want to.”

Easy, right? Well, kind of. If you run the code listing above from the VFP Command Window, and if your Windows DPI setting has been set to 144dpi with DPI Virtualization turned on, you’ll get the correct (truthful) font factor from Windows (when you follow the API call with the code listing from a previous post).

BUT, remember this function has told Windows that this process is DPI-aware. And since you’re running the code from within the VFP IDE, you’re essentially telling Windows that Visual FoxPro is DPI-aware.

Unfortunately, Visual FoxPro is not DPI-aware, and has already been “DPI virtualized” by Windows. Causing Windows to suddenly accept that Visual FoxPro is DPI-aware can wreak havoc with the IDE.

If you don’t trust me on this, try it. It’s u-g-l-y!

So, one way we can force Windows to accept the fact that our app is DPI-aware is to simply call the SetProcessDPIAware function – preferably as early in your app as possible. I have seen several forum postings which report calling the function too late can cause Windows to continue to “lie” and use DPI virtualization anyway, though I have not recreated this problem myself.

 

Using Your App Manifest File

Another way to tell Windows Vista (and 7) that the app is DPI-aware is to add the following section to your app manifest file:

<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
   <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <dpiAware>true</dpiAware>
   </asmv3:windowsSettings>
</asmv3:application>

If you are not sure about manifest files and adding manifest resources to your Visual FoxPro applications, I recommend the following articles (I’ve been using Markus’ Manifest Tools in my work):

Calvin Hsia: Add a Manifest to Control Your Application Vista UAC Behavior

Craig Boyd: Apply Application Manifest At Compile Time With ProjectHook

Markus Winhard: ManifestTools.zip (based on code from Calvin’s blog above)

If you are not comfortable with messing around with manifest files, the SetProcessDPIAware API function is the way to go. Just be sure it only runs on Vista/Win7/Win8 (or call it in a TRY-CATCH-ENDTRY block) to prevent an error in pre-Vista versions of Windows!

Additional thoughts and (better) explanations of DPI-awareness in Vista can be found in the following article: http://www.rw-designer.com/DPI-aware

by Kevin Ragsdale

Windows Is Lying To You… With DPI Virtualization

Windows lies, and Kevin cries, because his apps are blurry…

DPI Virtualization in Windows

Windows Vista (and subsequently, Windows 7 & 8) introduced a new feature called DPI Virtualization.

DPI Virtualization means Windows will automatically “resize” your forms and form objects for you, with no coding or resizing required on your part.

Sounds great, doesn’t it? Well, not quite. Remember my “ugly” form in an earlier post, running at 144dpi? It was DPI Virtualized by Windows 7, and the result was a blurry window.

DPI Virtualization also requires the code listing from a previous post to fail, every time. Why? Because when the code asks Windows, “Hey, what’s the current setting?”, Windows Vista, 7 and 8 will always answer “your font factor is 1” (no resizing required) if the user has selected to use DPI Virtualization.

“Whoa, whoa, whoa, Kevin! If the user has selected DPI Virtualization?”

Yes. Windows Vista, 7 and 8 have two different modes of DPI scaling: XP Style, and DPI Virtualization.

Setting the DPI scale mode in Windows 7

Setting the DPI scale mode in Windows 7

If the user changes her DPI setting, and checks the “Use Windows XP style DPI scaling” checkbox, Windows Vista, 7 and 8 will return the expected (truthful) result from the previous code listing – just like XP did.

So, a DPI of 144dpi (150%) with this box unchecked, results in the following:

The correct font factor with XP style scaling turned on

The correct font factor with XP style scaling turned on

And, just like I would do with the XP result from earlier, I would want to resize my forms and form objects, making them 50% larger than “normal.”

But if the user has not checked the box, here’s what Windows tells me about the “font factor” (notice the messagebox is also a bit blurry):

Thanks, Windows, for lying and making my forms blurry

Thanks, Windows, for lying to me and making my forms blurry

Great. The user has selected 144dpi, but my app does not know this because Windows has said, “Don’t worry, no need to resize anything. All is good.”

And my user gets to see “somewhat” resized, yet blurry, forms in my app.

What we need is a “Windows Lie Detector” to make sure Windows stops lying to us.

How do we do this?

We need to tell Windows that the app is “DPI Aware”.

And that’s exactly what we’ll look at in tomorrow’s post.

 

Related Links (With much better explanations)

High DPI Settings In Windows
Fixing Windows Programming