The two functions ME_FindItemAtOffset and ME_RunOfsFromCharOfs were almost
identically used, since ME_FindItemAtOffset was always used to find a run.
The only difference was how they returned the offset within the run for an
end of paragraph run.
For ME_FindItemAtOffset it would return the next run if it was in between \r
and \n. ME_RunOfsFromCharOfs would instead return an nOffset of 0 for end
paragraph runs. This subtle difference introduced bugs, so I decided to
avoid having special case in this function when creating this patch, and
instead let the caller handle this case.
EM_GETTEXTRANGE allows the start character offset and end characters
offset to be used to specify the range of text to retrieve. If the
start offset is in the middle of an end of paragraph run (i.e. \r\n),
then it should only retrieve the characters after the specified
character offset.
I found that ME_FindItemAtOffset and ME_CursorFromCharOfs are used
almost identically, except for how they handle a character offset that
is between a carriage return and line feed. In this case
ME_CursorFromCharOfs sets the cursor's run offset to 0, but
ME_FindItemAtOffset instead returns the next run which is what was
causing ME_LINELENGTH to incorrectly return the length of the next
line.
Previously this wasn't properly tested for, since all the lines had
text of the same length, so it wasn't properly testing to see which
line length it was getting.
riched32.dll does preserve the carriage returns and line feeds unlike
later versions of the richedit control, however the tests previously
missed the fact that a sequence of carriage returns followed by a line
feed (e.g. \r\r\r\n) can actually cause multiple paragraph breaks.
Several carriage returns followed by a line break were being handled as
a single paragraph break, when actually native richedit controls may
count this as several line breaks.
Dylan Smith