The application Blitzin2 was sending WM_VSCROLL messages to the
richedit control directly, when normally this message is supposed to
be a notification sent after the scrollinfo is set. Native richedit
controls always use the 16-bit value passed to this message to set the
scroll position for SB_THUMBPOSITION, rather than trying to find a
32-bit value through GetScrollInfo like I had previously done.
The missing return was to prevent automatic vertically scrolling when
style for it is not set, but is set for the horizontal scrollbar. I
initially missed this by testing with no autoscrolling on either
scrollbar.
Rich text files have groupings of text, where styles are pushed onto
the stack when encountering a start of the group, then popped at the
end of the group. This was being handled improperly before, because a
single styleChanged flag was being stored to keep track of whether the
style needed to be restored at the end of a group. This fails to work
properly since the single flag isn't keeping track of all the levels
of the stack, so some styles are not restored properly.
When a colour table entry is empty, then the default colour is used.
For an incomplete colour table entry 0 is used for the missing colours.
Previously the -1 value used internally for missing colours was being
converted into white, where it should be using the default colour that
is normally black.
This bug could be seen by loading the following rich text into wordpad:
{\rtf{\colortbl;;}\cf1 text}
Previously after initial window creation of a richedit control with the
ES_DISABLENOSCROLL window style flag the scrollbar would be shown but
not disabled. This patch fixes this issue by explicitly disabling and
showing the scrollbar.
When the richedit control is created without the ES_AUTOHSCROLL or the
ES_AUTOVSCROLL, then scrolling isn't done automatically when moving the
cursor with the arrow keys, drag selecting with the mouse, or even from
using the EM_SCROLLCARET (based on testing using a modified version of
wordpad).
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.
Dylan Smith