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.
The preview is now drawn onto it's own window rather directly onto
the client area of the top level window. This is done to allow for
scrollbars, since the page won't usually fit in the window when zoomed in.
Refactoring was needed as a result of this, and in order to provide more
granularity for updates to avoid EM_FORMATRANGE messages being sent when
the page the same page is being displayed.
EM_FORMATRANGE will set rc.bottom within the FORMATRANGE struct to be the
bottom of the area actually printed to, so this must be reset between calls
to make sure that the page boundaries are consistent between the pages.
The cbSize field for the REBARBANDINFOW structure was previously set to
the sizeof(REBARBANDINFOW), however, new fields were added to this
structure for newer version of windows. Testing in Windows XP (or with
comctl32.dll from Windows XP) I found this larger size was rejected
causing the rebar to not be displayed in wordpad.
The bug could be seen by inserting tabs stops 1cm, 2cm, & 10cm. The
10cm tab stop would be inserted before 2cm since the comparison isn't
based on the numeric value.
David Hedberg