The existing tests were not properly testing the return value for the case
where all the text fits in the page rect, so this patch adds a couple of
simple tests for this case.
The parent window for the richedit control on creation is the one that
receives notify messages, even after the parent has been changed using
SetParent.
The test that succeeded from this change was as a result of allowing the
end of the character format change be specified using NULL as the rest
of the text. Before, the end paragraph run at the end of the text was
not being set for this case, when all the text was supposed to have its
character format changed.
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.
The width for EM_SETTARGETDEVICE is used by some applications to set the
wrapping width to a certain distance in twips. This can be used even
though the target device is ignored.
Using the WS_VSCROLL style causes the ES_AUTOVSCROLL option to be set,
and using the WS_HSCROLL style causes the ES_AUTOHSCROLL flag to be
set (except with richedit v1.0).
The contents of the text can be zoomed in with EM_SETZOOM, or with the
mouse wheel. EM_SETZOOM is implemented, but these tests show bugs in
the implementation, and zooming using the mouse wheel isn't
implemented at all yet.
This fixes inconsistencies shown in the tests I added for the
WM_GETDLGCODE. The tests covered different cases handled by the
current implementation in order to show that the native implementation
is simpler for all these cases.
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.
There were several methods that do not have a HRESULT for a return
value, so returning E_NOTIMPL is not appropriate. For all the BOOL
return values FALSE was returned to indicate the operation was not
performed.
EditWordBreakProc documented the third parameter as being the number
of unicode characters in the string for richedit 2.0 and up. It turns
out that it should actually be the number of bytes in the string.
For some reason EM_POSFROMCHAR was returning 0 when the position was
equal to the end of the text, or beyond the end of the text. Instead
it should use the position at the end of the text for both these
cases. The x value was also seen to be offset by 1 according to the
tests.
Previously the shortcuts for cut, copy, paste, undo, redo, and select
all were being handled during the WM_CHAR message. These tests show
that these shortcuts should be handled with the WM_KEYDOWN message
instead.
There were some notifications that weren't sent in ME_UpdateRepaint
while redraw was disabled, so this verifies that they are not sent
with redraw disabled.
The test for EM_GETLINE was testing to make sure the null terminating
character was written at the end of the text as long as the buffer was
long enough, and also tested to make sure that no other bytes were
written after this null terminating character. This is consistent with
Windows 2000 and up, but not for previous versions of Windows.
The values returned by EM_SETPARAFORMAT and EM_GETPARAFORMAT previously
indicated an error, and the included tests shows that Windows behaves as
documented.
This is a minimal model of what happens in Corman Lisp 3.0 -
subclassed window class that unconditionally calls ShowScrollBar() to
force scrollbar visibility.
Some applications have never heard of ES_DISABLENOSCROLL and attempt
to force scrollbars to be always shown (with ShowScrollBar() or
similar) when otherwise richedit would hide them. If richedit attempts
to wrestle control back, a recursive loop of requests can result if
app overrides WM_SIZE behavior. Apparently native never reads the
scrollbar state, and operates from some sort of internal state, so
that scrollbars can be modified externally without native trying to
wrestle back control. This is confirmed by attached tests. An
exception: EM_SCROLL will restore visibility to a scrollbar that was
forcibly hidden.
EM_AUTOURLDETECT tests are taking too much time, so this patch tests
just one URL and one non-URL for all messages but WM_SETTEXT. Also,
remove one trace that spams the output needlessly.
This also reverts commit 2b52dd845097f16076c0185b02a003f63898dcab:
wordpad: Empty the richedit undo buffer on creation.
The reverted commit I created to fix an issue that only applied to Wine,
but it just masked the issue which was in richedit controls. The
default character format was set in two places while wordpad was
starting up, and caused wordpad to have two undo items at startup.
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.
Consecutively typed characters are grouped together to be undone
together. The grouping of typed characters can be stopped by certain
events that are mentioned in MSDN's remarks on the EM_STOPGROUPTYPING
message, which is also implemented by this patch.
Opening a text file with a NULL terminated character in it was causing
an assertion error after a run was being split due to word wrap.
Windows allows NULL terminated characters to be in the text.
Using Ctrl-RightArrow to move to the start of the next word did not
previously work when at the start of a word. This means that
Ctrl-RightArrow would not work twice in a row since it should move to
the start of the next word.
Default richedit font (System) in Windows causes richedit to report
CFM_BOLD as always set. Switch to Courier New in order to see that
richedit really sets the CFM_BOLD attribute in the correct selection.
Michael Stefaniuc