Finding how a header file gets included

Have you ever had a header file generate warnings that is not explicitly part of your Visual Studio solution?

Recently I’ve been working on fixing static analysis warnings reported by Microsoft’s PREfast static analysis tool for C++. I ran in to an issue though with some of the Microsoft Windows SDK v6.0 headers. One file, aptly named `strsafe.h`, can be the cause for tons of warnings in a build.

I looked around and found that the Windows SDK team is fully aware of the problem. They recommend wrapping the include for strsafe.h with pragmas, like so:

#include <CodeAnalysis/warnings.h>
#pragma warning(push)
#pragma warning(disable: ALL_CODE_ANALYSIS_WARNINGS)
#include <strsafe.h>
#pragma warning(pop)

So the first thing I did was to search through my code and find out who what included strsafe.h. But it turns out that no file explicitly included it. I figured that it must get included from another include file.

To find out what files are included in your build, you can turn on /showIncludes through the Project Properties ➨ Configuration Properties ➨ C/C++ ➨ Advanced ➨ Show Includes

/showIncludes prints out a tree of all of the files that get included in when the project is built. Using this, I was able to find which SDK files we included that ended up including strsafe.h.

This process took me about a half hour in total from turning the compiler flag on, performing a rebuild, narrowing down the includes, and wrapping them with pragmas. I still got a nasty taste in my mouth for suppressing the warnings, but getting rid of them cut out a lot of noise surrounding actual warnings that are more pressing.

MFC Dialog Data Exchange

I’ve been surprised to learn that there are developers who have worked in MFC for a long time and never really knew much about Dialog Data Exchange. I don’t fault them, since the easiest way to stumble upon it is through the Forms Designer’s context menu (besides seeing it in the generated code and having no clue what it does).

Dialog Data Exchange (DDX) is a really nifty feature that MFC brought forward to use when working with user interfaces. DDX strongly types variables and controls in the Dialog/Form’s associated class to the objects found in the UI.

This means you can get rid of GetDlgItem. Why does this help? Besides removing code and tons of enums interspersed throughout your code, it allows the ability to subclass a control easily with minimal code changes. Here is a short example:

Right-aligning text with CDC::SetTextAlign

Aligning text in an MFC application dialog can be done in many ways. I’ve seen some that calculate the width of the text it is going to print and then recalculate the CRect that the text should be placed it to give it the look of being aligned.

Today I was trying to do just that and was looking through the MSDN documentation for the different method calls when I stumbled upon CDC::SetTextAlign. The MSDN documentation reads:

UINT SetTextAlign(
   UINT nFlags
);

TA_RIGHT   Aligns the point with the right side of the bounding rectangle.
TA_CENTER   Aligns the point with the horizontal center of the bounding rectangle.
TA_LEFT   Aligns the point with the left side of the bounding rectangle. This is the default setting.

Specifies text-alignment flags. The flags specify the relationship between a point and a rectangle that bounds the text. The point can be either the current position or coordinates specified by a text-output function. The rectangle that bounds the text is defined by the adjacent character cells in the text string. The nFlags parameter can be one or more flags from the following three categories. Choose only one flag from each category. The first category affects text alignment in the x-direction: