One more RichEdit bug, pardon: "feature"

[jj2007]

MSDN on the GETTEXTLENGTHEX structure:

GTL_PRECISE
Computes a precise answer. This approach could necessitate a conversion and thereby take longer.

GTL_CLOSE
Computes an approximate (close) answer. It is obtained quickly and can be used to set the buffer size.

GTL_NUMCHARS
Returns the number of characters.

GTL_NUMBYTES
Returns the number of bytes.

Totally clear? So how many bytes are there in Windows.inc...?

1901020 bytes for GTL_CLOSE or GTL_NUMBYTES
950510 bytes for GTL_CLOSE or GTL_NUMCHARS
950510 bytes for GTL_PRECISE or GTL_NUMBYTES

::) ::) ::) ::)

Source attached, extract with "use folder names" to \Masm32\examples\exampl06\riched\richeditBug.asm, then use console build. Line 314ff:

      mov tlex.codepage, CP_ACP
      mov tlex.flags, GTL_CLOSE or GTL_NUMBYTES
      invoke SendMessage, hRichEd, EM_GETTEXTLENGTHEX, addr tlex, 0
      print str$(eax), " bytes for GTL_CLOSE or GTL_NUMBYTES", 13, 10

      mov tlex.codepage, CP_ACP
      mov tlex.flags, GTL_CLOSE or GTL_NUMCHARS
      invoke SendMessage, hRichEd, EM_GETTEXTLENGTHEX, addr tlex, 0
      print str$(eax), " bytes for GTL_CLOSE or GTL_NUMCHARS", 13, 10

      mov tlex.codepage, CP_ACP
      mov tlex.flags, GTL_PRECISE or GTL_NUMBYTES
      invoke SendMessage, hRichEd, EM_GETTEXTLENGTHEX, addr tlex, 0
      print str$(eax), " bytes for GTL_PRECISE or GTL_NUMBYTES", 13, 10

[Antariy]

It seems they forget to mention something "small irrelevant detail". From combination you found, Jochen, it looks like GTL_PRECISE is automatically imply GTL_NUMCHARS flag. Probably that can be explained just like "Precise - is a precise number of chars in a control, because it contains an Unicode characters, which are longer that a single-byte characters, that's why it requires conversion and takes longer" - but the first part of the message was omitted somewhere, and the only tail is revealed ::)
Well, at least you researched this detail (just like we told somewhere about "small details missed in docs" here) yourself :t

[hutch--]

If I have it right after years of using richedit 1, 2 & 3, there are different versions of richedit depending on the styles and options selected and each has bugs of its own. In QE I wanted the multi-level undo-redo and this produced some very irksome bugs, especially on line number reporting. I had to write a very unusual work around to get it to work reliably and it was purely a bug in the rich edit design that followed from the selected styles.

The original richedit was a lot less buggy but had a lot less capacity where the later 2 & 3 could do a lot more but with an "interesting" set of built in bugs.

[TouEnMasm]

explain from msdn:

This message is a fast and easy way to determine the number of characters in the Unicode version of the rich edit control. However, for a non-Unicode target code page you will potentially be converting to a combination of single-byte and double-byte characters

There is a conversion to do but which ?.

[Antariy]

explain from msdn:

This message is a fast and easy way to determine the number of characters in the Unicode version of the rich edit control. However, for a non-Unicode target code page you will potentially be converting to a combination of single-byte and double-byte characters

There is a conversion to do but which ?.

WideCharToMultiByte or similar.

[TouEnMasm]

After a little search it seems that things are more clear,here the result.

The EM_GETTEXTLENGTHEX message prepare the call of the EM_GETTEXTEX message.The EM_GETTEXTEX message fill a buffer with the content of the richedit in any format.He need to know the size of the buffer to allocate,it is the EM_GETTEXTLENGTHEX  message who give it the size.
There is the UNICODE format and various other format depending of the code page.
Here a sample:

954 Ko (977 412 octets) txt       size of file on disk
bytes for GTL_CLOSE or GTL_NUMBYTES  :1901030    ;size buffer for UNICODE
bytes for GTL_NUMBYTES                 :950562               ;size ANSI buffer
bytes for GTL_PRECISE or GTL_NUMBYTES :950610

It seems that the GTL_CLOSE  had a bad explain on his use.IT give the size for the UNICODE format.
In any case the given size is to used by the EM_GETTEXTEX message,and no other use

[jj2007]

977 412 octets size of file on disk
GTL_NUMBYTES  :950562               ;size ANSI buffer

crlf flag??

[TouEnMasm]

crlf flag??

Just an experiment to see the changes of the buffer size.