That seems to work after the content is displayed (i.e. OnDocumentComplete()), but using the offscreen rendering technique, the width and height still return 0. :sigh: I am still interested to know how to determine the width and height of an offscreen HTML document, if you have any suggestions. However, thank you for answering my original question!

Hrm. That seems to return the size of the client area, not the size required to display the document. I have the following in my class derived from CDHtmlDialog, in an overridden ShowContextMenu() handler. LONG nHeight, nWidth; IHTMLDocument2 *pDocument; IHTMLElement *pElement; GetDHtmlDocument(&pDocument); pDocument->get_body(&pElement); pElement->get_offsetHeight(&nHeight); pElement->get_offsetWidth(&nWidth); TRACE("Document width = %d\n", nWidth); TRACE("Document height = %d\n", nHeight); pElement->Release(); pDocument->Release(); CRect rect; GetClientRect(&rect); TRACE("Client width = %d\n", rect.Width()); TRACE("Client height = %d\n", rect.Height()); ASSERT(nWidth == rect.Width()); ASSERT(nHeight == rect.Height()); The width and height are always equal to the respective attributes of the client rectangle. Using the technique from http://www.codeproject.com/internet/parse_html.asp, the document width and height are always 0. Am I missing something?

Is there a way to determine the size of the rendered content of a CDHtmlDialog? - Rob

I am creating a CDHtmlDialog that is not going to be the size of the rendered HTML in all cases (i.e. it could be much larger than the HTML I am dynamically placing in it). I want to resize the dialog to be approximately the size of the rendered HTML. I do have a control at the bottom of the dialog, and my thought is: if I could get the control's window position, I could resize the dialog accordingly. Unfortunately, I haven't the foggiest of how to do this. Any ideas?

To enable full row highlighting in a list control: m_ctrlList.SetExtendedStyle(m_ctrlList.GetExtendedStyle() | LVS_EX_FULLROWSELECT); - Rob

I'm allowing a user to enter data in a wizard, and I want to confirm their intention if they are to click on Cancel. One would think overriding OnCancel, popping up a message box, and then NOT calling the base class method if the user did not intend to quit would be sufficient to keep the property sheet from closing... but this is not the case. Simply return'ing instead of calling the base class method closes the dialog anyway. Is there a way to return to the property sheet? I know something similar can be done with CDialog, which is why the property sheet is confusing. Here is the code:

// Handle the Cancel button
void CPageFieldSelection::OnCancel()
{
// Confirm
int result = MessageBox("Are you sure you want to exit?"...);

// Only cancel if they clicked YES
if (result != IDYES)
	return;

CPropertyPage::OnCancel();

}

The return closes the dialog, as does the CPropertyPage::OnCancel(). :omg: Any help would be appreciated. - Rob

Is there a simple way to use ONE dialog for a dialog-based application, yet still be able to maintain each screen separately in the dialog editor? It seems most wizards use a single dialog-- yet creating nice looking dialogs from scratch (i.e. without the dialog editor) is a complete pain. An example of a wizard that appears to use one dialog in its wizard is Winzip. I believe InstallShield has a similar appearance. Right now I am creating separate classes for each dialog; calling EndDialog() when the user presses NEXT, and then creating the next dialog. This does not appear to be standard, and sticks out like a sore thumb. Any help would be appreciated. :-D - Rob

Oops, sorry, wrong forum. ;)

Is there a simple way to use ONE dialog for a dialog-based application, yet still be able to maintain each screen separately in the dialog editor? It seems most wizards use a single dialog-- yet creating nice looking dialogs from scratch (i.e. without the dialog editor) is a complete pain. An example of a wizard that appears to use one dialog in its wizard is Winzip. I believe InstallShield has a similar appearance. Right now I am creating separate classes for each dialog; calling EndDialog() when the user presses NEXT, and then creating the next dialog. This does not appear to be standard, and sticks out like a sore thumb. Any help would be appreciated. :-D - Rob