CDHtmlDialog Class 

According to the CSS 2.1 specification the HTML canvas has a fixed scaling factor of 96 dots per inch (DPI).  It is the responsibility of the user agent (MSHTML.DLL) to scale the actual fonts and images up/down to accommodate the DPI of the physical display. This makes life much easier for the web designer, as it allows for precise layout of fonts and images because the CSS ratio 1pt=1.33px is constant.  You can set the virtual DPI to 96 by adding the flag DOCHOSTUIFLAG_DPI_AWARE to your call to CDHtmlDialog::SetHostFlags in your override of OnInitDialog.  This allows you to lay out your dialog precisely (including bitmaps) regardless of the display's actual physical DPI.

However the dialog window does not scale linearly.  The size of your HTML dialog box is set in your .rc file and is measured in Dialog Units (DLUs). To convert DLUs to pixels at 96 DPI multiply x by 1.4 and y by 1.666.  The problem is that Windows uses integer arithmetic to determine the dialog size. Windows converts the DLU to Dialog Base Units (DBUs), where 1 horizontal DBU = 1/4 horizontal DLU and 1 vertical DBU = 1/8 vertical DLU. At 96 DPI, 1 horizontal DBU = 6 and 1 vertical DBU = 13.  The integer approximation of 6/4 (1.5) has an error of roughly 7% relative to the desired horizontal scaling factor (1.4).  And 13/8 (1.625) has an error of 2.5% relative to the desired vertical scaling factor (1.666).

Because of the rounding errors your dialog box dimensions will vary depending on the physical DPI.  For example let's assume that you design your CDHtmlDialog layout at 96 DPI and make it look perfect. Then you go look at the result at 120 DPI, only to find that the dialog box has unexpectedly shrunk by 7% horizontally, messing up your fine layout. (The layout didn't actually 'shrink' at DPI 120, but rather it was too wide at 96 DPI.)

The workaround is to manually compute the desired dialog size using floating-precision arithmetic, then rescale the size of the CDHtmlDialog window by hand. Or design your CDHtmlDialog to be tolerant of shrinkage of the canvas width (e.g., turn off CSS nowrap or set overflow: auto).

Trying to use CDHtmlDialog in an MFC Extension DLL can result in the dialog's browser saying it can't access the page.

CDHtmlDialog does not search the MFC module chain for the HTML resource; it creates a URL out of the current resource module, which is typically the .EXE.  So, when you create the window, you need to establish this .DLL as the current resource module.  Be sure, afterwards, to restore the default resource module before returning to other code.

Here is an example for a modeless dialog, for a modal dialog you'd be surrounding the DoModal() call instead of the Create() call:

    HINSTANCE hSaveResourceHandle = AfxGetResourceHandle();
AfxSetResourceHandle(AfxFindResourceHandle(MAKEINTRESOURCE(IDR_HTML_MYCOOLPAGE), RT_HTML));
Create(IDD_MYWRAPPERDIALOG, pParentWnd);
AfxSetResourceHandle(hSaveResourceHandle);

(Checking for a NULL return from AfxFindResourceHandle and wrapping this into a class so that a destructor restores the default resource handle are left as exercises for the reader.)

Note:  In an MFC Extension DLL, and **cannot** use AFX_MANAGE_STATE(AfxGetStaticModuleState()).