I noticed a while ago that on Windows XP richedit controls ignored
characters typed while the mouse is captured (e.g. from holding the left
or middle button down). Arrow keys, delete, and backspace, copying,
cutting, pasting, and everything else handled on WM_CHAR and WM_KEYDOWN
messages are also ignored.
Certain operations will simply not be done for windowless richedit
controls, such as WM_PAINT which isn't done for windowless richedit
controls since ITextServices provides a TxDraw method.
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).
Windowless richedit control will not be able to call GetCapture without
a handle to the host window (and there is no ITextHost_TxGetCapture
method), but there is a ITextHost_TxSetCapture method available for
setting and releasing the capture on the mouse. This means that the
richedit control will need to keep track of whether it has captured the
mouse or not to implement windowless richedit controls.
Previously the WM_NCCREATE was handled by the as if it was always for
later versions, then the window proc for version 1.0 would make
appropriate changes afterwards. Instead both versions should call the
same function (e.g. ME_MakeEditor) and provide the value for
bEmulateVersion10 to make the code clearer.
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.
When the character or paragraph format is changed the paragraph that
is changed is already marked to be rewrapped, so ME_MarkAllForWrapping
shouldn't be called. Since ME_RewrapRepaint uses this function, it
shouldn't be called in these circumstances, since rewrapping all the
text can cause noticable delays when working with a lot of text.
On WM_DESTROY the editor was getting freed, then it was used to obtain
a handle to the editor. This patch moves it just before the editor is
freed within ME_DestroyEditor.
In order to make the message handling available to windowless richedit
controls, the message handling must be in a function that can be
called from the ITextServices_TxSendMessage method. This method will
never have a handle to a window to pass to RichEditWndProc_common in
order to get the editor with GetWindowLongPtrW, but passing the editor
will work (even if hWnd is NULL).
During wrapping there were three different heights that were being
stored, with only one of them being done correctly. The other ones
failed to incorporate the height of the paragraph or row, so ended up
being incorrect.
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 RichEditWndProc_common function is big enough already by handling
all the window messages, so moving code to handle a message to its own
function makes the code more readable.
There is no reason for the rich text format parser to need a handle to
the window, and even if there were it has a handle to the editor which
contains a handle to the window. It is better to remove this
considering we need to cut down on the use of window handles to
implement windowless richedit controls.
The vertical scrollbar state is stored internally within the control,
so should be used when possible. This will become more necessary when
windowless richedit controls are implemented, and there will no hWnd
to pass to GetScrollInfo.
Comparing the editor as apposed to the handle to the window will work
just as well right now, but will also work when there is no window
handle to make a comparison with, which will be the case with
windowless richedit controls.
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.
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 control words in skipped groups were being processed by
the read hook on the RTF parser. By moving this code into the class
callbacks for the parser, the skipped groups actually remain skipped.
For simple tables cells are represented with tabs, and a table row is
ended at the end of the paragraph, so native richedit controls
substitute spaces for \tab and \par rich text format control words.
The values returned by EM_SETPARAFORMAT and EM_GETPARAFORMAT previously
indicated an error, and the included tests shows that Windows behaves as
documented.
The problem was that the paragraph format was being retrieved,
slightly modified and then used to set the paragraph format, without
limiting the mask to what was being set. The PFM_OFFSETINDENT mask flag
being valid meant that dxStartIndent specifies a relative offset, thus
dxStartIndent was doubled.
When the cursor is moved over the selection bar, without holding any
mouse buttons down, the cursor would be repeatably set between the
normal cursor, set by DefWindowProc for the WM_SETCURSOR message, and
the reversed cursor, set by ME_MouseMove.
I created a function to set the default paragraph format to ensure
consistency when this is done. This initial paragraph format is also
now more consistent with native richedit controls. The dwMask value
always appears to have the same value when retrieved from the native
richedit controls, so all the mask values are now initialized when the
PARAFORMAT2 structure is created.
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.
Checks were added for hexadecimal values that did not have valid
characters, and for EOF received before the final closing brace of the
rich text stream. The error values were tested on richedit versions 1,
2, 3 & 4.1, and they were all the same for these cases.
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.
The call to GetClientRect returns 0 values for the returned RECT when
called in WM_NCCREATE in on Windows, which ended up causing an assertion
error when Wine's riched20.dll replaces the native version. Moving the
call to WM_CREATE fixes this problem (probably because NCCALCSIZE is
called in between).
Dylan Smith