One might suggest the following answer:

• Set "Accept Files" property to True in Properties Window for the edit control, which is False by default.
• Add WM_DROPFILES handler to the message map of the dialog that hosts the edit control.

However this seemingly standard routine does not provide DAD capabilities for the edit control. You can additionally set "Accept Files" property for the dialog that hosts the child edit control to enable DAD for the whole dialog area, but this DAD design would mislead the user a little bit since DAD icon would show up not only over the edit control, but over the whole dialog area. The right solution to enable DAD for the edit control only is to add WM_DROPFILES handler to the edit control itself and you need to subclass edit control to handle control messages in own procedure. The code from the MFC_EditWithDAD sample shows how to implement subclassing starting from boilerplate MFC dialog application with edit control added in dialog template in the Resource Editor:

• Add a class CEditWithDAD derived from CEdit. You can use the code that VS.NET generates when deriving from a standard MFC class:

  // CEdit is subclassed to handle dropped files.
  class CEditWithDAD : public CEdit
  {
      DECLARE_DYNAMIC(CEditWithDAD)
  
  public:
      CEditWithDAD();
      virtual ~CEditWithDAD();
  
  protected:
      afx_msg void OnDropFiles(HDROP hDropInfo); // added manually
      DECLARE_MESSAGE_MAP()
  };
  

• Add CEditWithDAD class variable, m_ctlEditWithDAD, to the dialog class.
• Add WM_DROPFILES handler, ON_WM_DROPFILES(), to the message map of the CEditWithDAD and its default function OnDropFiles:

  // Works for single files and for a folder.
  void CEditWithDAD::OnDropFiles(HDROP hDropInfo)
  {
      TCHAR szFFN[MAX_PATH];
  
      // MSDN (second parameter): "If the value of the iFile 
      // parameter is between zero and the total number of files
      // dropped, DragQueryFile copies the file name with the 
      // corresponding value to the buffer pointed to by the 
      // lpszFile parameter."
      DragQueryFile(hDropInfo, 0 /* iFile */, szFFN, 
                                    sizeof(szFFN)/sizeof(TCHAR));
      DragFinish(hDropInfo);
  
      // Update text in the edit control.
      SetWindowText(szFFN);
  }
  

• Subclass "normal" edit control which was previously positioned in the dialog template in the Resource Editor as:

  BOOL CMFC_EditWithDADDlg::OnInitDialog()
  {
      <...>
      // Subclass edit control.
      m_ctlEditWithDAD.SubclassWindow(
                                   GetDlgItem(IDC_EDIT)->m_hWnd);
      
      return TRUE; 
  }
  

That's all. Now you can DAD (drag-and-drop) files to the edit control to check that the full file name is automatically inserted with the drop. The same code works for folders. Notice that the use of SubclassWindow has the advantage for it allows to use positioning of the edit control in the dialog template.

To start with, there is no standard method to read CHM file version information since it is not supposed to be in CHM file by design. Right-click any CHM to verify that there is no Version tab. There are no options in Microsoft Help Workshop to add version information.

Is there a simple possibility to add version information and read it in Win32 or MFC application? The answer is yes: Microsoft compiler for help files that produces CHM files does not encode file names included into a help project. Hence there is a possibility to add version information to a name of HTM file and read this information from an application.

Microsoft Help Workshop compiles help files into CHM file (compiled help file) that is essentially an ANSI text file. Look what Notepad++ shows:

It shows a plain name of HTM file added to help project. The file name includes version information. Then the method to add read version information is the following:

• In Microsoft Help Workshop, add _Version_.htm file. The file can be empty and there is no need generally to add it to Table of Contents (HHC file), the sole purpose of it is to keep version information in its file name.
• In your application read CHM file as you would read any ANSI file, search for "<projectname>_Version_<x.x>.htm" string and parse it to extract version information.

This method is demonstrated in Win32_GetCHMVersion sample application. In this sample the About dialog shows version information in the static field.

As the following code shows it uses ReadFile to get CHM file content into a buffer, and then searches for the version string. The only little complication is that CHM file contains many NUL characters and therefore C-functions that are used to find substrings or characters in a string (like strstr, strchr) can not be used. In this sample the memchr is used to find the first character of the string in raw CHM file.

In general, the steps to employ this method for an application are the following:

• Add <projectname>_Version_<x.x>.htm file with version information to your existing Help Project file (HHP file) and compile it.
• Modify the AboutDlg_OnInitDialog function updating the location of CHM file, the search character (the first character in the name of added version information file), and adjusting the size of szBuffer according to the comments below. Update search string and constants in the code.
• The result is the szVersion string that is shown in the sample in the About dialog. Customize how the result is handled.

BOOL AboutDlg_OnInitDialog(HWND hDlg)
{
    // Help file is supposed to reside in the project root folder 
    // while the executable is in the Release or Debug folder.
    char szCHMFileName[] = "..\\GetCHMVersion.chm"; 
    int  ch = 'G';  // search character
    HANDLE hCHMFile;
    // The buffer should be big enough to hold characters beyond 
    // the "GetCHMVersion_Version_1.0.htm" string in CHM file, 
    // but generally less than CHM file size. 
    char szBuffer[2000]; 
    DWORD dwBytesToRead = sizeof(szBuffer);
    DWORD dwRead;
    LPBYTE  lpCurr = NULL;
    int nSearchDepth;
    int nNextPos;
    LPBYTE  lpStart = NULL;
    char szTarget[100];
    char szVersion[10];
    char* pszVersion = NULL;
    BOOL bFound = FALSE;

    hCHMFile = CreateFile(szCHMFileName, GENERIC_READ, 
        FILE_SHARE_READ, NULL /* security is off */,          
        OPEN_EXISTING /* opens file if exists or fails */,
                      FILE_ATTRIBUTE_NORMAL /* normal use */, NULL);

    if (hCHMFile != INVALID_HANDLE_VALUE)
    {
        ReadFile(hCHMFile, szBuffer /* out */, 
                  dwBytesToRead /* in */, &dwRead /* out */, NULL);

        // Since the szBuffer contains many NUL characters, memchr 
        // is used to search for "GetCHMVersion_Version_<x.x>.htm" 
        // string. The memchr-search is enabled up to the end of 
        // the buffer (the exact position where the search must be 
        // ended is not essential).
        nSearchDepth = sizeof(szBuffer); 
        lpCurr = (LPBYTE)memchr(szBuffer, ch, nSearchDepth);
        // Return FALSE if the search character was not found.
        if (lpCurr == NULL) return FALSE;
        // Calculate the position next to the found character
        // relative to the beginning of the buffer.
        nNextPos = (int)((char*)lpCurr - szBuffer + 1);

        while (nSearchDepth > 0)
        {
            // The new position to start search.
            lpStart = lpCurr + 1;
            // The size of remaining chunk of characters that 
            // were not searched.
            nSearchDepth = nSearchDepth - nNextPos;
            lpCurr = (LPBYTE)memchr(lpStart, ch, nSearchDepth);
            // Return FALSE if the search character was not found.
            if (lpCurr == NULL) return FALSE;
            nNextPos = (int)((char*)lpCurr - (char*)lpStart + 1);

            // Check if found position corresponds to 
            // "GetCHMVersion_Version_<x.x>.htm" string, get the 
            // version, and if not, continue the search. First, 
            // extract the 29 characters that might be 
            // "GetCHMVersion_Version_<x.x>.htm" string (without 
            // NUL since anyway szTarget is NUL-terminated when 
            // initialized).
            strncpy(szTarget, (char*)lpCurr, 29); 
            if (strncmp(szTarget, 
                 "GetCHMVersion_Version_", 22) == 0 /* equal */)
            {
                bFound = TRUE;
                break; 
            }
        } // while cycle

        if (bFound)
        {
            // Get the version string that is in  format.
            pszVersion = szTarget + 22;
            *(pszVersion + 3)  = '\0';
            strcpy(szVersion, pszVersion);

            // Show the version string in the About dialog.
            SendMessage(GetDlgItem(hDlg, 
                IDC_ABOUT_STATIC_VERSION), 
                   WM_SETTEXT, 0 /* not used */, (LPARAM)szVersion);
            return TRUE;
        }

        CloseHandle(hCHMFile); 
    }
    else
    {
        MessageBox(NULL, "CHM Help file was not found.", 
                                 "CHM Version", MB_ICONINFORMATION);
    } // hCHMFile check

    return FALSE; // either CHM file or version string is not found 
}

The sample is limited to <x.x> version strings. However the code that is easy to update to read version strings like 1.28 or 10.124 or 1.15.23.

Have you ever noticed a question mark in the title area of virtually any Windows XP dialog next to close button? The screenshot below is an example from the application as familiar as WordPad. In the WordPad's Print dialog when you click the question mark (the cursor takes immediately a question shape), then click a control (or text) in question - a yellow (typically) popup window brings up the context help.

This is an example of context help in action. In general, the following context help support can be implemented:

• "?" Help: click with "?"-shaped cursor on the control in question after you click "?" in the title area of a dialog.
• SHIFT+F1 Help: when control has focus SHIFT+F1 brings up the same context help as for "?" Help.
• "What's This?" Context Menu Help: when control has focus right-click on the control brings up "What's This?" window. The following click on the window brings up the same context help as for "?" Help and SHIFT+F1 Help. You can check out "What's This?" help with the WordPad application.
• SHIFT+F1 Help for the Menu Items: when menu item is active SHIFT+F1 bring up the context the menu item. This usually does not work for root menu items and menu items that have subitems. Notably typical Microsoft appications do not always have this type of context help support. For example, SHIFT+F1 Help for menu item is not implemented for Microsoft's WordPad and Notepad applications. On the contrary, Microsoft Word, Excel, Outlook 2000 support this type of help.

The following download provides an example of F1 and context help implementation in the MFC application. The application's Help system samples “bigger scale” overview with CHM file invoked with F1 and “smaller scale” hints for the controls and menu items in question invoked with different mehods of context help. At the center of the sample is CContextHelpMappings class developed to facilitate providing context help for typical Win32 and MFC applications. The details of the logic are the following:

• F1 should always invoke CHM file (MFC_SHIFT_F1_Help.chm) except for the case when cursor is inside the rectangle of the control that has focus. In this case, the context help for the control is shown.
• The "?" Help, SHIFT+F1, "What's This?" context types of help should bring up the same context help windows based on ID of the control in question.
• There is some difficulty with intercepting F1 since “?”, SHIFT+F1, F1 are all generate WM_HELP message handled in MFC with OnHelpInfo handler. Therefore the check is made in the beginning of OnHelpInfo if the WM_HELP relates to F1. In the result, F1 help is handled in the separate handler (OnF1Help function of the sample) of the application class albeit all help (F1 and context help) originally handled with MFC's OnHelpInfo handler. The method used in the sample to sort out F1 events figures if the cursor is inside the rectangle of a control that has focus and if not it decides that this a general help request for F1. An alternative method would be to use MFC's PreTranslateMessage to analyze help request.
• The CHM file does not (although it can in general) handle context help support. The rationale is that the frequently more convenient context help options are: (a) keep context help tightly bundled with an application (user/development perspective), (b) keep context help hard-coded (developer perspective). For example, when CHM file is missing (not yet downloaded, deleted) the context help is still available. Notably hard-coded context help helps to reduce download traffic since CHM file can frequently reach the size of the associated application or bigger. In this case, one can implement the option to download CHM help while not including CHM file into the setup.

Let's suppose an application has many dialogs and windows that require context help support. Where does one handle context help? In general, it is reasonable to handle context help in one location such as application class. By this we avoid duplicating context help functionality in each dialog and save quite a bit of efforts. The following is CContextHelpMappings class that helps to handle all context help in typical Win32 or MFC application. Notice that according to the CContextHelpMappings template each control has a pair of IDs. The m_MapMainDialog array keeps all these ID pairs in one place. The first ID in each pair, is control ID (with "IDC_" prefix) and the second is help ID with "IDH_" prefix. You should add help IDs manually according to the control namings e.g. for IDC_MD_BUTTON1 add IDH_MD_BUTTON1.

#pragma once

class CContextHelpMappings
{
public:
    // Initialize the context help mappings in the constructor.
    CContextHelpMappings()
    {
        // Mappings for the main dialog. 
        m_MapMainDialog[0].nControlID = IDC_MD_BUTTON1;
        m_MapMainDialog[0].nStringHelpID = IDH_MD_BUTTON1;
        m_MapMainDialog[1].nControlID = IDC_MD_BUTTON_HELP;
        m_MapMainDialog[1].nStringHelpID = IDH_MD_BUTTON_HELP; 
        <...>

        // Mappings for the options dialog.
        m_MapOptionsDialog[0].nControlID = IDC_OD_BUTTON_OPTION1;
        m_MapOptionsDialog[0].nStringHelpID = IDH_OD_BUTTON_OPTION1;
        m_MapOptionsDialog[1].nControlID = IDC_OD_BUTTON_OPTION2;
        m_MapOptionsDialog[1].nStringHelpID = IDH_OD_BUTTON_OPTION2; 
        <...>		
    }
		
    // Set the size of arrays. Notice that "const static" helps 
    // initialize outside the constructor, but inside the class and 
    // keeps initialization in the one place. 
    const static short m_nMapSizeMainDialog = 5;
    const static short m_nMapSizeOptionsDialog = 5;

    struct ContextHelpMap
    {
        DWORD nControlID; 
        DWORD nStringHelpID;
    } m_MapMainDialog[m_nMapSizeMainDialog], 
                           m_MapOptionsDialog[m_nMapSizeOptionsDialog];
};

The next are the more elaborative steps to implement context help using CContextHelpMappings class in MFC application (Win32 steps are essentially the same):

• Add CContextHelpMappings member variable to the application class so that the variable would be accessible from any MFC dialog with theApp reference:

  #include "ContextHelpMappings.h"
  
  class CMFC_SHIFT_F1_HelpApp : public CWinApp
  {
  // Constructor(s) and destructor (constructors).
  public:
      CMFC_SHIFT_F1_HelpApp();
  
  // Access member variables (attributes).
  public:
      CContextHelpMappings m_ContextHelp;
  <...>
  };
  
  extern CMFC_SHIFT_F1_HelpApp theApp;
  

• Add to the resource.h the values for the new help IDs e.g. for IDC_MD_BUTTON1 (value 123) add IDH_BUTTON1 (value 2123). The value for the help ID is arbitrary as long it is unique. In this sample, the value for help ID is the value of relative control ID plus 2000. This keeps help IDs ordered.
• Add help strings to the RC file. To keep all strings in one place is one of the basic purposes. You can edit RC with any text editor adding strings like:

  STRINGTABLE 
  BEGIN
      IDH_MD_BUTTON1             "Test button."
      IDH_MD_HELP_BUTTON         "Show CHM help."
      <...>
  END
  

• In each dialog class where you want ot implement context help add OnHelpMenu handler, which (a) handles all WM_HELP messages such as related to "?" Help, SHIFT+F1, (b) redirects to OnF1Help messages related to F1, (b) process messages redirected from OnContextMenu that handles "What's This?" context help. Since "What's This?" help is originally handled (WM_CONTEXTMENU message) with OnContextMenu handler, you should add it too. The sample shows the implementations of OnHelpMenu and OnContextMenu functions that should be a bit customized for each dialog to reflect CContextHelpMappings's names of variables for context menu IDs mappings in the dialog.
• Finally, add to the application class OnF1Help handler to handle F1 help so that that each dialog can access the handler.

When you need to provide color pickup option for an application, you may want to show current color within some area without invoking color selection dialog, and show newly selected color within the same area. One option to make this is to use small colored bitmaps and set a bitmap with specific color for static control. Another option, which is more economic (since does not require additional bitmaps), is to paint the background area of static control with specific color. Here is how the result looks like:

You can examine the Win32 code here. In a nutshell you add SS_OWNERDRAW style to static control, and handle WM_DRAWITEM message in window procedure of static control's owner window (main window in sample application) to paint its background color. In sample application the static control is created with CreateWindow, but you can surely use Visual Studio dialog template, drag-and-drop static control and add SS_OWNERDRAW style to RC file.

Sounds simple? Indeed it is a fairly straightforward method, which has however some pitfalls if you're are not careful about details:

• You should adhere to fairly standard receipt of painting an area. That is, firstly, you save current device context before painting, and return it to the system when finished with painting. Secondly, you should backup in similar way current system brush object (or more generally GDI objects) used for painting background, and restore system brush when finished with painting. In between, you use device context provided with painting method that is in our case represented by the device context provided with WM_DRAWITEM message to paint an area:

  	
  case WM_DRAWITEM:
          if (wParam == IDC_STATIC_OWNERDRAW) 
          {
                  lpdis = (LPDRAWITEMSTRUCT) lParam; 
                  if (lpdis->CtlID == IDC_STATIC_OWNERDRAW)
                  {
                          // Standard painting procedure is to save   
                          // system DC, brush (SaveDC, SelectObject)   
                          // before using custom, and restore to saved when  
                          // finished with SelectObject, RestoreDC.
                          nSavedDC = SaveDC(lpdis->hDC); 
  
                          hBrush =  CreateSolidBrush(g_clrBkgroundColor); 
                          hOldBrush = (HBRUSH)SelectObject(lpdis->hDC, 
  						hBrush);
                          FillRect(lpdis->hDC, &lpdis->rcItem, hBrush);
                          SelectObject(lpdis->hDC, hOldBrush);
  
                          DeleteObject(hBrush);
                          RestoreDC(lpdis->hDC, nSavedDC);
  
                          return TRUE;
                  }
          }
          break;
  

  Notice that Select function serves two purposes: loads newly created brush and returns system brush, which must be saved for later restore. This cooking receipt for painting shows that when finished with painting, we still need to inform the system that our own work is done by returning TRUE so that the system does not make own painting.
• Do not presume that if you set owner-draw style for static control with SS_OWNERDRAW style, and other controls do not have this sort of style, WM_DRAWITEM will not be generated while painting client areas for other controls e.g. button control. In fact, try to comment this line in the handler above:

  	
  case WM_DRAWITEM:
          // if (wParam == IDC_STATIC_OWNERDRAW) 
          lpdis = (LPDRAWITEMSTRUCT) lParam; 
          if (lpdis->CtlID == IDC_STATIC_OWNERDRAW)
  

  As the result, the sample application may crash (access violation reading error) when you pickup a color from color dialog or even when invoke About dialog and click OK. When repainting the system sends also WM_DRAWITEM message for button control (you can check out wParam, which is the control ID, to see that) even though the button does not have owner-draw style. For some reason the WM_DRAWITEM message for button is spurious, and DRAWTIMESTRUCTURE members are not defined as seen from the debugging output (VS.NET 2003), which corresponds to handling of WM_DRAWITEM sent with wParam containing button ID:

  

  The access violation can be easily avoided by sorting out WM_DRAWITEM messages to handle only those messages where wParam equals ID of static control.

• When you finished with selecting a color from colors dialog and click OK, force application to repaint static control with newly selected color. You can do in different fashions using InvalidateRect, RedrawWindow, SetWindowPos, or sending WM_DRAWITEM to static control explicitly with SendMessage provided that DRAWITEMSTRUCT is properly filled. For example as in the sample:

  RedrawWindow(g_hwndStatic_OwnerDraw, 
      NULL /* invalidate entire client area */, 
           NULL /* invalidate entire client area */, RDW_INVALIDATE); 
  

• The g_clrBackgroundColor variable that stores color from color selection dialog should be global, not local to WndProc, since WM_DRAWITEM message relative to owner-draw static control can be caused not only due to RedrawWindow when color selection dialog is closed, but also due to main window resize, About dialog close.

The sample is generated with VS.NET 2003 (can be imported to VS.NET 2005 with no changes in source files). You can see changes made to skeleton application generated with Win32 Wizard of VS.NET 2003 by using UI-enabled compare tool such as Beyond Compare 3:

• Slide left to right
• Slide right to left
• Slide top to bottom
• Slide bottom to top
• Collapse inwards
• Collapse outwards
• Blend (hide)
• Blend (show).

The sample demonstrates the animation that realized with AnimateWindow Win32 function. The steps to make animation in MFC applications are essentially the same. To make AnimateWindow function operate correctly there are a couple of essential points to notice:

• All painting relative to AnimateWindow occurs in respond to WM_PRINTCLIENT or WM_PRINT messages. This differs from handling of painting in typical window, which occurs in respond to WM_PAINT message. In fact, when implementing painting caused by AnimateWindow you can safely forget about WM_PAINT message since it is not even sent. You don't need to implement painting in response to both WM_PRINTCLIENT and WM_PRINT, it is enough to realize painting in response to WM_PRINTCLIENT message only (alternatively you can use WM_PRINT only).
• Making a certain type of animation requires setting relative animation flags as third parameter of AnimateWindow function. In fact, this parameter is frequently combination of flags and it can be quite tedious and troublesome to figure out what combination is required for certain type of animation. As a cooking receipt the following table enlists combination of flags that make possible corresponding animation in sample application:

  Animation Type	Animation flags
  Slide left to right	AW_SLIDE | AW_HOR_POSITIVE
  Slide right to left	AW_SLIDE | AW_HOR_NEGATIVE
  Slide top to bottom	AW_SLIDE | AW_VER_POSITIVE
  Slide bottom to top	AW_SLIDE | AW_VER_NEGATIVE
  Collapse inwards	AW_HIDE | AW_CENTER
  Collapse outwards	AW_ACTIVATE | AW_CENTER
  Blend (hide)	AW_BLEND
  Blend (show)	AW_BLEND | AW_HIDE

• Though description of AnimateWindow function does not say it specifically, the call to AnimateWindow function should be preceded by functions like ShowWindow or SetWindowPos. Without such call the animation does not work (I have never heard that it is possible to make animation with a single call to AnimateWindow). Anyway such receipt works in sample application.
• Finally, the window used for blend animation cannot be a child window, and must be a top-level window. This requirement does not relate to other types of animation.

If you use screen resolution other than 1280x1024 the window used for blend animation will be somewhat misadjusted in relation to the application window, but it has nothing to do with animation itself, which should work fine (you may want to update one line of code in provided sample if you prefer another resolution).

1. Navigate user to internet location by single click.
2. Set URL font and color.
3. Set cursor (usually hand cursor).

Handling single click for internet navigation

You handle click event to launch IE with specified URL by handling command message in About's dialog procedure (no subclassing is required for this task), and by doing this you'd implement the major and most simple part of the task:

case WM_COMMAND:
        if (LOWORD(wParam) == IDC_STATIC_LINK)
        {  
                ShellExecute(NULL, "open", 
                        "http://netston.tripod.com", 
				0, 0, SW_SHOWNORMAL);		
        }

Setting font and color of static control

You can set font (size and underlining) by handling WM_INITDIALOG message in About's dialog procedure with custom SetFont(HWND hDlg) function like this:

void SetFont(HWND hWnd)
{
        HFONT hfnt;
        LOGFONT lf;

        // Specify the font to use (stored in a LOGFONT structure).
        lf.lfWidth = 0;
        lf.lfEscapement = 0;
        lf.lfOrientation = 0;
        lf.lfWeight = FW_DONTCARE;
        lf.lfUnderline = TRUE; // underlining
        lf.lfStrikeOut = FALSE;
        lf.lfCharSet = DEFAULT_CHARSET;
        lf.lfOutPrecision = OUT_DEFAULT_PRECIS;
        lf.lfClipPrecision = CLIP_DEFAULT_PRECIS;
        lf.lfQuality = DEFAULT_QUALITY;
        lf.lfPitchAndFamily = FF_DONTCARE;

        _tcsncpy(lf.lfFaceName, _T("Arial"), 32);

        hfnt = CreateFontIndirect(&lf);
        SendMessage(GetDlgItem(hWnd, IDC_STATIC_LINK),  
	                           WM_SETFONT, (WPARAM)hfnt, TRUE);
}

if (GetDlgItem (hDlg,IDC_STATIC_LINK) == 
		(HWND)lParam /* handle to static control */)
{
        SetTextColor((HDC)wParam /* handle to display context */, 
						RGB(0, 0, 255));
        // Use TRANSPARENT so that background is not changed while 
        // drawing a text.
        SetBkMode((HDC)wParam /* handle to display context */, 
						TRANSPARENT); 
        // If the dialog box procedure returns FALSE, then default
        //  message handling is performed.
		
        return (BOOL)GetStockObject(HOLLOW_BRUSH); 
}

Setting hyperlink cursor

case WM_INITDIALOG:
        g_wpOldWndProc = (WNDPROC)SetWindowLong(
            GetDlgItem (hDlg, IDC_STATIC_LINK), GWL_WNDPROC, 
				(DWORD)StaticSubclassedFunc);

LRESULT APIENTRY StaticSubclassedFunc(HWND hWnd, UINT Message, 
				    WPARAM wParam, LONG lParam)
{
        ::SetCursor(LoadCursor(NULL, IDC_HAND));
}

• Toolbar pictures are not separate resources. In fact, all pictures should be located on a single bitmap strip (BMP file).
• Bitmap strip consists of 16 [width]x15[height] pictures, where sizes mesured in pixels. So if your application has 10 toolbar pictures, you would need to provide 160x15 pixels bitmap resource. Windows is quite untolerating to other bitmap heights. For example, if you use 16x16 pictures your application would likely crash. The use of not default picture sizes requires a bit of additional work.
• You cannot change toolbar's color depth in Visual Studio image editor. By default, toolbar pictures have 4-bit color depth (16 colors). In contrast, you can change color depth for icon resources, and for the bitmap resources. The use of not default color depths requires some additional work.
  
  To change icon color depth, you need to create new icon at first (since "device" property is read-only), and then choose image type in Image menu. The color depth for bitmaps is read/write, and can be changed directly in its properties.
  
  By the way, icon resources in VS.NET 2005/2003 can be 1 (monochrome), 4 (16 colors), 8 (256 colors), 32 (> 16 milions colors) bits depth. You can view, but cannot create 32-bit color icon in Visual Studio.

• The toolbar's backgroud should be painted with menu color. In color palette position cursor over the grey and right-click. The palette's symbolic rectangle representing backgroung color turns grey:

  

  Now, erase tool can be used to paint with the grey background color.
• There is always fresh new area for the next image in the top editor's frame. If you leave it unpainted, this area does not matter i.e. it is not translated finally into RC file. To tell image editor that you want to add a new image, merely begin to paint last button area (new clean button area is automatically added to the right as soon as one pixel is painted).
• Pressing Delete does not removes the image from the toolbar, you need to drag it off the toolbar area. Dragging is also the way to move a button.
• Last (not obvious!) trick is about making a separator area on the toolbar. You need to drag a button to the right or left (approximately one half the button width) a make space between buttons. When you save RC file, Visual Studio automatically adds SEPARATOR line in toolbar code. In the similar way, the separator space is removed (guess how).

As we saw editing toolbar as toolbar resource is a bit tricky. There is also an alternative way to create a toolbar and you might find it more convenient. Start with a bitmap resource and then, after you finished with adding pictures, turn it into toolbar resource. It is more straigtforward process, but remember that toolbars are 4-bit resources, and if you created your bitmap as 8-bit (256 colors) resource, and want to convert it into a toolbar (right-click in the any of image editor's panes and choose Toolbar Editor...), you will see a message "Toolbars can only contain 16 colors ..." that will prompt you to automatically decrease color depth to 4-bit. You might have avoided it if you had started your bitmap as 4-bit resource!

• Open/closing tags should be within the same line.
• Only one pair of open/closing tags within the same line.
• No spaces between tag value and surrounding open/closing tags.
• XML file is ANSI text file (e.g. Windows-1252 encoding).
• Build with UNICODE.

1. Read entire XML file, find a line with target line to update (e.g. tag name "OrderBy").
2. Read into a separate string top part of the XML file (before the targeted line).
3. Read into a separate string bottom part of the XML file (after the targeted line).
4. Updated targeted line into a separate string.
5. Concatanate and write entire XML file as new one (delete file and create new one, ANSI).

RECT rc;
HBRUSH hbrush;

rc.left = 600; rc.top = 100; rc.right =  700; rc.bottom = 200;

hbrush = CreateSolidBrush(RGB(255,0,0));
HDC hdc = GetDC (hwnd); 
FillRect(hdc, &rc, hbrush);

DeleteObject(hbrush); 
ReleaseDC(hwnd, hdc);

• How to delete an empty directory in Win32? The answer is to use simply RemoveDirectory function.
• How to delete not empty directory in Win32 that has files, but does not have subdirectories?
• How to delete an empty directory in Win32 that has files and subdirectories? The answer is to use the code.

• Declare in shared header file (such as stdafx.h) extern global variable:
  
  #include <string>
  using namespace std;
  extern string g_s;
• Re-declare global variable in one implementation file and initialize it to some value:
  
  string g_s;                        // file scope
  g_s = "global variable"; // initialization function

BOOL CMySSPropPageWelcome::OnNotify(WPARAM wParam, 
                                              LPARAM lParam, LRESULT* pResult)
{
        PSHNOTIFY* pPSHNOTIFY = (PSHNOTIFY*)lParam;

        char szPath[200];
        LPTSTR pszPath;
        SearchPath(NULL, "MySS.chm", NULL, 200, szPath, &pszPath);
    
        switch (pPSHNOTIFY->hdr.code)
        {
        case PSN_HELP:

            ::HtmlHelp(NULL, szPath, HH_DISPLAY_TOPIC, 0);
            return -1; // message handled, no futher actions
            break;
        }

        // Contitue handling notification messages other then PSN_HELP
        return CPropertyPage::OnNotify(wParam, lParam, pResult);
}


LRESULT CMySSPropPageWelcome::OnWizardNext()
{
        // ...
        return CPropertyPage::OnWizardNext();
}

CFont font;
font.CreateFont(12,                            // nHeight
                0,                             // nWidth
                0,                             // nEscapement
                0,                             // nOrientation
                FW_NORMAL,                     // nWeight
                TRUE,                          // bItalic
                FALSE,                         // bUnderline
                0,                             // cStrikeOut
                ANSI_CHARSET,                  // nCharSet
                OUT_DEFAULT_PRECIS,            // nOutPrecision
                CLIP_DEFAULT_PRECIS,           // nClipPrecision
                DEFAULT_QUALITY,               // nQuality
                DEFAULT_PITCH | FF_SWISS,      // nPitchAndFamily
                "Tahoma");                     // lpszFacename