Using the ITextHost interface allows this notification to be received
for windowless richedit controls. Windowed richedit conrols have an
ITextHost implementation that will fill in hwndFrom and idFrom, but
these should probably be initialized to 0 for windowless richedit
controls.
Images that are inserted into richedit controls store a space for the
text, since that is the character returned when getting the plain text
from the control.
When calculating the width of a line, the space character is skipped,
but images should not be skipped. This can be seen by inserting an
image into wordpad on a line by it's own, then centering the line. The
image will start from the center rather than being centered in the
control.
These functions were just being used for addition, so it was simpler to
remove the functions and modify the places it was used.
The ME_StrRelPos2 and ME_PosToVPos were just simple wrappers around
ME_StrRelPos, and ME_PosToVPos wasn't being used.
These functions were probably previously needed because of some wierd
special handling of backspace characters, but currently there is no
reason why the nLen field can't be accessed directly.
Having to functions that just access the string length field just causes
slightly more effort for someone to look at the code, because they need
to enter the function to find out what it actually is doing.
More case of searching for the paragraph through the linked list when
is was already previously available. Since each wrap context is used
for wrapping each paragraph, I decided to add the reference to the
paragarph in the structure.
The width for EM_SETTARGETDEVICE is used by some applications to set the
wrapping width to a certain distance in twips. This can be used even
though the target device is ignored.
The methods in ITextHost are mostly thin wrappers around functions that
take a handle to a window as their first parameter. This patch just
uses the wrapper functions provided by ITextHost instead of using the
functions that require a handle to a window that the editor might now
have (for windowless richedit controls).
When the text is wrapped, the positions for all the runs, paragraphs,
and cells are already calculated and stored. The only thing left to do
for painting is to offset them by the formatting rectangle and the
scroll position.
During wrapping there were three different heights that were being
stored, with only one of them being done correctly. The other ones
failed to incorporate the height of the paragraph or row, so ended up
being incorrect.
The formatting rectangle is set with EM_SETRECT, and retrieved with
EM_GETRECT, so it corresponds to rcFormat in the code. This defines the
area that the richedit control should draw the text so that it is
offset by the top-left corner of the formatting rectangle, and clipped
so that it doesn't draw past the bottom or right hand side. Thus this
is important for implementing windowless richedit controls to not
interfere with the rest of the window.
The assertion was not valid, because it neglected to take into account
the situation where a line break is forced with a MERF_ENDROW run
(caused by \line control word or pressing Shift-Enter). This means
that spaces can cause a line wrap after a forced line break as well as
after a paragraph break, so we cannot assert that it is the first row
in the paragraph.
The uncommon case that this patch handles is enough whitespace being
on the first line of a paragraph to cause it to wrap. In this case the
first non-space character will be wrapped onto the next line.
Dylan Smith