An easy way to use Skins in a Dialog based Application

Preparing the Project and Adding Resources

Before any custom skin can appear on a dialog, the foundation must be solid. In an MFC application that follows the dialog‑based model, the majority of visual work happens inside the dialog class derived from CDialog. The first step is to create a new project in Visual Studio using the “MFC AppWizard” and choose the “Dialog based” template. Once the project skeleton is in place, you can add a bitmap that will serve as the skin. The bitmap must be placed in the resource file (.rc) and given a unique identifier, such as IDB_MAIN. This image can be any shape or style you like – a simple rectangle, a rounded corner splash, or a full‑screen texture.

With the resource ready, the dialog header file needs to declare a handful of members that will hold the bitmap, the client region, and the window region. These members are essential for creating the non‑rectangular window that matches the shape of the skin image. The header might look like this:

The m_hBmp member will hold the loaded bitmap. The client region can be used to clip controls or to create a custom shape for the dialog’s client area, while m_hWndRgn is the actual region applied to the dialog window, making it non‑rectangular. The DIBToRgn function will later translate a bitmap into an HRGN by examining pixel colors and building a region that matches the opaque parts of the image.

In the constructor of the dialog, the bitmap is loaded using LoadImage with the LR_CREATEDIBSECTION flag so that it can be accessed in 32‑bit format. After loading, the code creates an elliptical client region and converts the bitmap into a window region. The elliptical region is optional; it simply demonstrates how you can create a custom client shape before the skin is applied. A typical constructor might look like this:

Here, RGB(0, 255, 0) is the background color that the DIBToRgn function will treat as transparent. The Direct flag tells the function whether to treat matching pixels as a continuous run or to evaluate each pixel individually; passing FALSE creates a more precise region.

With these steps, the project is set up: the dialog class knows how to load the skin, it holds a handle to the bitmap, and it has the necessary infrastructure to generate a region that will later shape the window. This preparation stage keeps the code clean and modular, letting you focus on the more intricate region‑generation logic in the next section.

Implementing Skin Support in the Dialog

Having the basic members and constructor ready, the heart of the skinning process is the DIBToRgn function. This routine walks through every pixel of the bitmap, determines whether it belongs to the opaque part of the skin, and collects a list of rectangles that will be merged into a single region. The function is designed to be efficient: it scans line by line, groups contiguous opaque pixels into horizontal runs, and stores those runs as RECT structures in a buffer. Once enough rectangles are collected, the function merges them into an HRGN using ExtCreateRegion and the RGNDATA structure.

The function starts by setting a tolerance value that controls how strict the color comparison is. Pixels whose color falls within a range defined by the tolerance around the background color are treated as transparent. This approach handles minor color variations caused by anti‑aliasing or compression artifacts. The following excerpt shows the initial setup and the color range calculation:

Once the 32‑bit DIB is ready, the function copies the original bitmap into it and begins scanning the pixels. It uses a loop over the height and width of the bitmap. For each row, it walks through the pixels, comparing their RGB values to the background range. If a pixel matches the tolerance, it either starts a new run or continues an existing one, depending on the Direct flag. When a run ends, the function records the run’s start and end coordinates as a RECT and stores it in the region buffer. If the buffer fills up, the function creates a temporary region from the buffer and merges it into the main region using CombineRgn. This step ensures that the region never consumes too much memory at once.

After all rows are processed, a final region is built from any remaining rectangles. If the Direct flag is FALSE, the function also XORs the region with a rectangle covering the whole bitmap. This step effectively removes the background area, leaving only the opaque skin shape. The final region is then returned and stored in m_hWndRgn

In addition to region creation, the dialog needs to paint its background correctly. Overriding OnEraseBkgnd allows us to blit the bitmap directly onto the dialog’s client area. The implementation below creates a temporary memory DC, selects the skin bitmap into it, and uses BitBlt to copy the image onto the dialog. If the bitmap exists, the function returns TRUE to indicate that the background has been handled; otherwise, it falls back to the default MFC implementation.