On Mon, Mar 28, 2022, 4:10 PM Huw Davies <huw@codeweavers.com> wrote:
On Mon, Mar 28, 2022 at 12:41:12AM +0900, Jinoh Kang wrote:
> Signed-off-by: Jinoh Kang <jinoh.kang.kr@gmail.com>
> ---
>������ dlls/riched20/editor.c������ ������ ������ ������ | 6 ++++++
>������ dlls/riched20/tests/richole.c | 4 ++--
>������ 2 files changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/dlls/riched20/editor.c b/dlls/riched20/editor.c
> index 3d2d49af047..454a8bf5fc8 100644
> --- a/dlls/riched20/editor.c
> +++ b/dlls/riched20/editor.c
> @@ -4271,6 +4271,12 @@ int ME_GetTextW(ME_TextEditor *editor, WCHAR *buffer, int buflen,
>������ ������ ������ ������ nLen = 2;
>������ ������ ������ ������ str = L"\r\n";
>������ ������ ������ }
> +������ ������ else if (flags & GT_RAWTEXT && run->nFlags & MERF_GRAPHICS)
> +������ ������ {
> +������ ������ ������ srcChars -= min(nLen, srcChars);
> +������ ������ ������ nLen = 1;
> +������ ������ ������ str = L"\xfffc";
> +������ ������ }
>������ ������ ������ else
>������ ������ ������ {
>������ ������ ������ ������ nLen = min(nLen, srcChars);
> diff --git a/dlls/riched20/tests/richole.c b/dlls/riched20/tests/richole.c
> index 24284a24484..dc0d7c4e1f1 100644
> --- a/dlls/riched20/tests/richole.c
> +++ b/dlls/riched20/tests/richole.c
> @@ -3404,7 +3404,7 @@ static void test_InsertObject(void)
>������ ������ memset(buffer, 0, sizeof(buffer));
>������ ������ result = SendMessageW(hwnd, EM_GETTEXTEX, (WPARAM)&gettextex, (LPARAM)buffer);
>������ ������ ok(result == lstrlenW(expected_string), "Got wrong length: %ld.\n", result);
> -������ todo_wine ok(!lstrcmpW(buffer, expected_string), "Got wrong content: %s.\n", debugstr_w(buffer));
> +������ ok(!lstrcmpW(buffer, expected_string), "Got wrong content: %s.\n", debugstr_w(buffer));

The tests just before this show that GT_DEFAULT behaves in the same
way (which conflicts with the docs).������ Though it would be worth
hacking new_richedit() to create a MSFTEDIT_CLASS window to see if
that changes anything.

Test results show the following:

In riched20, U+FFFD is returned regardless of whether or not GT_RAWTEXT is specified. (maybe it didn't exist at all?)
In msftedit, GT_RAWTEXT is honoured for objects (as specified in docs).


I think the right thing to do is to store 0xfffc in memory (see
editor_insert_oleobj())

Great!

and fixup the other text getters that need to
return a space (possibly introducing a custom GT_ flag so this can be
done in ME_GetTextW()).

The question is: do other getters care at all? Perhaps we can leave GT_DEFAULT as-is, instead forcing GT_RAWTEXT in message handler if the control is in riched20 compatibility mode. This could use some more testing, though.


Huw.