The effect specifies whether underlining is turned on, while bUnderlineType
indicates the type of underlining.
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The first paragraph was being handled just by ME_StreamOutParaProps,
but subsequent paragraphs would check if the paragraph was starting or
ending a table. So I moved the code to check for tables into
ME_StreamOutParaProps.
This is a regression caused by commit
54b53b6018 which change the code to use
if statements instead of a switch, so the break statement should have
been changed to a continue statement.
Plenty of places in the code find following or preceding runs, then
afterwards find the paragraph from the run. This is inefficient because
the same linked list is used for both runs and paragraphs, so changes in
paragraphs can be detected while returning the next or previous run.
Previously the only convenient way to get the start and end of the
selection was through offsets, which eventually need to get converted
back into items in the linked list storing the text. The new function
will help with eliminating these inefficiencies.
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.
The ME_RunOfsFromCharOfs function finds the paragraph before finding the
run and offset within the run, so the function may as well be able to
return this paragraph to the caller. Many callers to the function
instead find the paragraph from the run, which ends up unnecessarily
traversing a linked list of runs within the paragraph.
Previously a count of the carraige returns and line feeds were stored
for end of paragraph runs, and a paragraph sign was stored as the actual
string. This was causing many special cases where the length of the
run needed to be determined differently if the run was or wasn't an
end of paragraph run.
There wasn't any use for storing the paragraph sign unless some drawing
code gets commented out to allow the end paragraphs to be shown,
therefore I changed the code to store the actual string that gets
retrieved by WM_GETTEXT.
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.
Michael Stefaniuc