WM_SETTEXT seems to check for {\rtf or {\urtf to determine if it is an
ascii RTF string, even if it is a unicode message. So I removed the
check to see if it is a unicode message, and added a check for {\urtf.
This was partially handled by ungetting the end group token (i.e. '}')
so that it was read again at the proper place. Unfortunately there is a
read hook that maintains a stackTop variable, which is decremented when
receiving this end group token. Therefore stackTop would get
decremented twice, and the rich text file would end prematurely.
This is fixed by incrementing the stackTop variable to compensate for it
being decremented twice.
Wine was not doing bounds checks for EM_GETTEXTRANGE, which was causing
a crash in Bug 17822. The added tests would cause a crash without the
added bounds checks in the richedit code.
The bounds checks I put in HandleMessage, since ME_GetTextRange is also
called for ME_GETSELTEXT which should not have bounds checks, since it
uses the selection range.
When the ME_GETTEXTRANGE message returns 0, no text is copied, not even
the NULL terminating charter. This differs from EM_GETSELTEXT which
will copy the NULL terminating character when no text is selected. This
behaviour is consistent with native 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.
EM_SETCHARFORMAT can be used to make text links. Automatic URL
detection being enable would cause these links to be removed if the text
is not a URL, so this must be prevented.
Previously checks were made for AutoURLDetect_bEnable before calling
ME_UpdateSelectionLinkAttribute, or ME_UpdateLinkAttribute. This is
more error prone than checking for this within the function, so one call
was missing this check.
ME_SetCursor also didn't respect this behaviour, since it wouldn't set
the cursor to the hand when hovering over a link without automatic URL
detection disabled.
Before the code was modifying the format rect to compensate for space
being added or removed for the selection bar, but this should only
happen when the ECO_SELECTIONBAR setting bit changes.
When all the text fits on the screen, the scrollbars are not shown from
EM_SHOWSCROLLBAR. The message instead adds support for the specified
scrollbar when lParam is TRUE, so that the scrollbar will be shown when
sufficient text is in the document.
The scrollbar visibility can be changed from SetScrollRange or
SetScrollInfo, but the visiblity that is a result of these calls are
not consistent with the calculation made by richedit controls to
decide whether to show or hide the scrollbars.
The ME_TextBuffer structure is what is used to store the document (as
a linked list), so the ME_Document structure isn't being used. There
was also a document pointer in the ME_Paragraph structure that was
also unused, so I removed it because it is probably related to this
used structure.
This prevents some needless searching for the start of the paragraph
from a run stored in a cursor. Usually a pointer to the paragraph is
already available when the cursor is set anyway.
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 two functions were being used for simple operations, to get the
first or last character when pre-computing flags for splitting runs.
The call to ME_GetCharBack wasn't even giving the correct result, it
would always return -1 since it is being called with nPos of 0.
This patch simplifies the code by removing the functions and getting the
characters directly from the string.
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 function was just returning the second parameter. It had some
commented out code that indicated that previously backslashes weren't
included in the length. Native wordpad doesn't handle backspaces in a
special way, so this must have been an internal representation that
complicated finding the position of characters.
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.
I found that ME_MakeStringB was previously unused, and that the other
ME_MakeString functions repeated code that was already in ME_MakeStringB.
Making ME_MakeStringB static and using it to avoid duplicate code seemed
like a better idea than removing the function.
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.
Wrapping is needed to be done even when repainting isn't done since
later messages expect line breaks to reflect the current text. Some
message can specify not to paint the sceen, but this should prevent
wrapping from being done.
- A HWND can be safely marshaled over a LONG as its payload is not
a pointer but a user handle.
- Use GetWindowLongPtr instead of GetWindowLong to retrieve a pointer.
When finding an adjacent paragraph, the next_para and prev_para pointers
should be used because they are direct pointers, a constant time
operation. Instead I found some places in the code that searched through
the general linked list to get to an adjacent paragraph, which is a linear
time operation, depending on the number of rows and runs in between
paragraphs.
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.
Dylan Smith