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.
ME_GetCursorCoordinates had two conditions that were always taken. The
first condition was if(pCursor->pRun->type == diRun) was following an
assertion making the exact same check. The next one, if(row), should
always be taken, otherwise the richedit controls are in a corrupt state,
therefore an assertion is more appropriate.
Previously it found the start or end by traversing the linked lists of
run, rows, paragraphs, and cells from the current position of the
cursors. Clearly it is better to get the start or end directly to make
it a constant time operation.
The fixme comment is suggesting wrapping a paragraph within a function
that is for moving the selection cursor up or down a line when the up
or down keys are pressed. The contents fo paragraph aren't being
changed, so there is no need to wrap the paragraph.
Rather than get the paragraph from the run, the function allows the
caller to provide the paragraph, since it is already available. This
reduces unnecessary traversals of lists that take longer as more runs
and rows are in the paragraph.
These calls to ME_WrapMarkedParagraphs never do anything, and don't make
sense to be called in these places. These places are for ME_MoveCaret,
and ME_ArrowHome, which both don't involve any text being modified, and
all (direct and indirect) calls to these functions are done after the
text has already been wrapped.
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.
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.
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).
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 code for the ME_EnsureVisible function does exactly what
EM_SCROLLCARET does, yet this code is duplicated in order to handle
this message. It is simpler to just use the existing function to
implement the message, and avoid internally sending the EM_SCROLLCARET
when this function is available.
After selection a word, line, or paragraph with multi click selection or using
the selection bar, then shift can be held and the arrows can be used to move
one of the ends of the selection.
The PARAFORMAT structure has a bit in wEffects to indicate whether the
paragraph is a table or not, so this should be used instead of a private
bTable value, since this structure can be retrieved with EM_GETPARAFORMAT.
The cursor should only be shown when there is no selection, since this
is how it is done in Windows. This patch avoids showing the cursor when
there is a selection, and destroys the cursor when a selection is made.
The caret's x position is stored in ME_TextEditor.nUDArrowX so that when
the caret is moved up or down, it will stay along the same horizontal
position, or at the end of a line. Unfortunately, the value stored in
nUDArrowX was being unconditionally discarded in ME_ArrowKey, preventing
it from serving its purpose.
Before the end of the text was selected when clicking below the end of
the text, rather than using the x position to find the appropriate
character on the last row that is closest to the pixel position.
When the caret is at the start of a run, it uses the font of the
previous run for inserting characters. The caret size previously was
the wrong height for the characters being inserted when the caret was at
the start of a line, but not the start of a paragraph so this patch
fixes this bug.
The function ME_GetInsertStyle already checks for the case where there
is a selection, so there is no need to duplicate this code for
ME_GetSelectionInsertStyle.
The function ME_FindRunInRow uses two parameters to return values by
reference, and treated these parameters as if they were optional except
for the start of the function which set *pbCaretAtEnd without checking
to see if was a NULL pointer.
The bCaretAtEnd value in ME_TextEditor is used to identify that the
caret is at the end of a wrapped line instead of the start of the next
line in the paragraph since both these positions correspond to the
same position in the document. The bCaretAtEnd value was previously
being set back to FALSE whenever the window was resized.
Document remaining uses of bEmulateVersion10 and other checks for CRLF in editor.c.
Make RTF reader emit a \r or a \r\n according to emulation, not a \n, which breaks streaming tests.
Remove todo_wine from a bunch of riched32 tests that now succeed.
Replaces duplicated scrolling code with re-usable functions.
Removes excessive boundary checking on scroll code, since that's done
in the scrollbar control anyways.
Properly separates repaint calls based on what has changed.
Send EN_UPDATE and EN_CHANGE at the right places.
Only call EnsureVisible on changes, not all repaints.
Optimized reading large texts into RichEdit to be an O(n) order
algorythm instead of O(n^2) by removing extraneous conversions of
character offsets to run offsets.
should greatly improve stability of the wrap code and eliminate
regressions of the most recent versions)
- completely new scrollbar handling (much more reliable) and related
redraw fixes
- Page Down handler (no Page Up yet, fixing wrap/redraw/scrollbar bugs
was of higher priority)
unnecessary repaints)
- added unicode character support to RTF import (like: \u12345 ?)
- small fixes
- fixed whitespace identification bug
- removed drawing of paragraph marks
- improved stub implementations for IRichEditOle
- ME_JoinRuns didn't mark the paragraph for rewrapping, fixed.
- Removed PostQuitMessage(0) from WM_DESTROY handler (duh!).
- Use of EM_GETOLEINTERFACE is reported with FIXME instead of TRACE
(any app using this message is likely to encounter major problems).
Dylan Smith