The rebar is the parent of the ruler, not the top level window, so
GetDlgItem was returning NULL when the window is resized. As a result the
screen was being invalidated and repainted instead of the ruler.
Either one or two pages may be shown in print preview when zoomed out.
This value is stored in the registry in native wordpad, and preserved
while opening and closing the print preview. Zooming in will only show one
page, but the pages shown value must be saved because it will return to the
preview pages shown value after unzooming completely. If two pages should
be shown when there is only one page of text, then a second blank page is
shown.
In print preview you can zoom in by left clicking on one of the pages. The
zoom cursor is displayed whenever the mouse is over the page to indicate to
the user that they can zoom in. When fully zoomed in it will zoom out when
this is done again. When clicking on the second page, it will zoom into
that page.
For print preview it will take more time to wait for the whole text to be
wrapped for EM_FORMATRANGE than to wait for just the first page. Trying to
get the total number of pages will cause the whole test to be wrapped.
Instead all that is needed is to just determine if a page is the last page,
which can be determined by it's page end offset compared to the text length.
This avoids having to delete the device context and the bitmap selected
into it just to update the bitmap, since it was setting preview.hdc to
NULL to indicate that these bitmaps needed to be updated. This patch
also helps make WM_PAINT messages get processed faster by moving this out
of the code for handling WM_PAINT.
Previously hdc2 needed to be deleted and set to NULL to indicate that only
one page should be shown. I have avoided this using a new variable for
the preview structure.
The device context were also being deleted without deleting the bitmaps
created for them and selected into them, so this patch also gets these
bitmaps and deletes them with their device context.
Rather than making seperate calls to EM_FORMATRANGE to get the number of
pages and the character boundaries, it would be easiest to get both
together. The time to process EM_FORMATRANGE seems like it would take a
lot longer than the time needed to cache the character page boundaries.
Previewly monochrome bitmaps were being created by CreateCompatibleBitmap
because the hdc passed into that call came from CreateCompatibleDC which is
initialized with a single pixel monochrome bitmap.
Gustavo Henrique Milaré