Tech Tips

Size Limitations for Device-Dependent Bitmaps
Stephen Schumacher
[email protected]

The Win32 API function CreateCompatibleBitmap() returns a device-dependent bitmap (DDB) having a specified pixel width and height. According to MSDN, “the created bitmap cannot exceed 16MB in size” under Windows 95/98. According to Feng Yuan (author of Windows Graphics Programming), the limit is around 48MB for Windows NT/2000.

However, long after testing and shipping a program, you may be dismayed to discover the undocumented fact that these numbers are only upper limits. Since the device driver (not Windows) does the work for DDBs, the actual maximum DDB size varies on a machine-specific basis. Trying to create a DDB that requires 8MB will fail on many machines, and even lower limits on certain machines cannot be ruled out. This can create problems when doing common tasks such as print previewing to the screen. For example, a bitmap representing an 8.5 by 11 inch printed page at 300 DPI (dots per inch) exceeds 8MB in 256-color mode (and exceeds 32MB in 32-bit True Color mode).

If you find that you need to deal with potentially large bitmaps, here are a few tips:

• For some applications, it may be practical (though unwieldy) to break large bitmaps into smaller chunks, then process each chunk individually.
• If color is not essential, use CreateBitmap() or CreateBitmapIndirect() to create a monochrome bitmap (1 bit per pixel). Monochrome bitmaps are compatible with all video modes and require less memory.
• Use CreateDIBSection() to create a device-independent bitmap (DIB) instead of a DDB. The practical limit for DIBs is available virtual memory (along with 16-bit coordinate addressing under Windows 95/98/ME). However, the down side is that DIBs can be much slower than DDBs, because they don’t operate on the driver level.
• The best approach can be a hybrid one: for the sake of speed, first use CreateCompatibleBitmap() to try to create a DDB. If that function indicates failure by returning NULL, then fall back and use CreateDIBSection() to create a DIB.

Custom Keyboard Navigation with Radio Buttons
Matthew Wilson
[email protected]

The Windows dialog manager provides keyboard navigation for dialog child controls, including handling the tab key and mnemonics. Modal dialogs created with DialogBox() receive this functionality automatically. For modeless dialogs, you must call IsDialogMessage() within your message loop. However, there are some situations where the default keyboard handling may not be enough. For example, web-page style windows, or embedded dialogs (where one dialog is placed as the child of another) often require additional processing by application code.

When implementing custom keyboard navigation, the most challenging task is usually dealing with groups of radio buttons. Consider the example of an embedded dialog (i.e., a dialog with DS_CONTROL that appears as a child of another dialog). Suppose the focus is on the third button of a radio group that happens to be the first item in the child dialog. When the user presses shift-tab, they reasonably expect the focus to go to the control in the parent dialog that precedes the child dialog (because it is visually the “previous” control). However, the default handling by the Windows dialog manager will cause focus to move to the last control (or control group) of the child dialog.

The way to obtain the desired behavior is by intercepting the messages within the message loop (in MFC, this is provided via the CWinThread::PreTranslateMessage() method), testing the current focus, and moving the focus to the “correct” control. In order to do this, you must be able to determine whether a control is a radio button and, if so, whether adjacent controls are part of the same group.

To help in this effort, I created IsRadioButton() and IsRadioPeer() shown in radio.c (Listing 1). Like the Windows dialog manager, IsRadioButton() uses the WM_GETDLGCODE message to query the control for its identity. If the control reports that it is a radio button, it is accepted as such. If not, I check for a specific window class (“BUTTON”) and control style (BS_RADIOBUTTON or BS_AUTORADIOBUTTON).

IsRadioPeer() makes use of IsRadioButton() and determines whether any two windows are peer radio buttons. It does this by first ensuring that they are siblings (they have the same parent window). Then the z-order is searched first forwards, and then backwards. If the potential peer is found before the search steps outside of the group, then it is indeed a peer radio button.

Both functions have been compiled and used successfully with Visual C++ 1.51, 4.0, 4.2, 5.0, and 6.0, as well as Borland C++ 3.01, 4.52 and 5.00. Example 1 contains a code fragment that demonstrates how these functions might be used for special handling of the Tab key.

Using Resources in MFC Extension DLLs
Thomas Gawehns
[email protected]

I recently wrote an MFC extension DLL that implements a dialog with its own resources. This poses a problem if your resource IDs overlap with IDs used by other extension DLLs. The recommended way to avoid trouble is to reserve resource IDs for all your extension DLLs to ensure uniqueness. I didn’t like this requirement, so I implemented a class to manipulate the global module handle that MFC uses to retrieve resources. Source code for the class is in setres.h (Listing 2).

An instance of this class remembers the old resource handle and sets the new resource handle for its lifetime. In my dialog constructor, I include the following code:

CMyDialogInDll::CMyDialogInDll()
{
    extern HINSTANCE theDllInstance;
    CSetResourceHandle block(theDllInstance);
    // access the resources here!!
    //
}

For the lifetime of the block variable, MFC will search my extension DLL resources first before looking elsewhere. This means that I don’t have to worry about whether my resource IDs overlap with resource IDs used by another DLL. When block goes out of scope, the destructor restores the previous resource handle. The global variable theDllInstance is initialized in DllMain() .

An Easy Way to Add Tool Tips to Any MFC Control
Zuoliu Ding
[email protected]

In my article “A Generic Tool Tip Class” (Windows Developer’s Journal, April 2001), I presented a reusable tool tip class named CTipWnd that you can use in place of Windows tool tip mechanism. In subsequent discussions with several readers, I realized that some implementation details need further discussion. Additionally, I’ve created a new helper class that can make it even easier to use CTipWnd.

As mentioned in the article, a parent window may not intercept the WM_MOUSEMOVE message for a child control because the child window eats this message without routing it to the parent. This occurs for nearly all Windows controls except static text items. I dealt with this in the article by deriving a class from a control like CButton, and dynamically subclassing the derived class to display a tool tip in its WM_MOUSEMOVE handler. This method is fine for controls that are all the same. But what if you have many different controls and want to add tool tips for each of them? (See Figure 1.)

To solve this problem, I create a helper class named CTipHelper to simply forward WM_MOUSEMOVE messages on to its parent. CTipHelper is implemented in tiphlpr.h (Listing 3) and has a single function, OnMouseMove(). CTipHelper::OnMouseMove() converts a cursor position from the control window coordinates to its parent window coordinates and then sends a WM_MOUSEMOVE to its parent. In the dialog’s OnMouseMove(), you can show tool tips for all contained controls uniformly. As a convenience, the macros SET_TIP_TEXT() and END_TIP_TEXT() are provided for this purpose.

Since CTipHelper is derived from the base window class CWnd, you can connect any control object to it. The implementation of the CTipDemoDlg class in tipdemo.cpp (Listing 4) illustrates how to use CTipHelper with CTipWnd to get the results shown in Figure 1. Of the 17 controls in the dialog, 14 of them are connected to CTipHelper; the exceptions are the static text, the icon, and the group box.

There are two approaches to getting the controls created and initialized. I added six members as Dialog Data Exchange (DDX) variables (e.g., m_ipAdr, an IP address control). You can first add them via ClassWizard and then change the definition type (e.g., change CIPAddressCtrl to CTipHelper). For the remaining eight controls, I took a different approach. I created an array, m_tipHelpers, and then subclassed each control during initialization. In both cases, you still can use the CTipHelper members anywhere, but a type cast is required if you call a method beyond those of CWnd, just as I did in OnInitDialog() .

In the dialog’s OnMouseMove(), I fill in a table mapping the desired tip strings to each control ID by using SET_TIP_TEXT() several times and END_TIP_TEXT() once at the end. These macros work with any type of control. The CTipWnd member (m_tip defined in CTipDemoDlg) takes the responsibility for hit testing and displaying the tool tip at the appropriate time. (See my article for complete details.) In order to demonstrate displaying context-specific text, I’ve included a check box to enable or disable the list box. Note that the tool tip text changes to reflect the current state. Source code for the example program and the CTipWnd class is available online in this month’s code archive.