MSDN (http://msdn.microsoft.com/en-us/library/windows/desktop/bb787915%28v=vs.85%29.aspx) 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
:greensml:
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
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.
explain from msdn:
Quote
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 ?.
Quote from: ToutEnMasm on May 31, 2013, 12:15:12 AM
explain from msdn:
Quote
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.
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:
Quote
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
Quote from: ToutEnMasm on May 31, 2013, 03:17:28 PM
977 412 octets size of file on disk
GTL_NUMBYTES :950562 ;size ANSI buffer
crlf flag??
Quote
crlf flag??
Just an experiment to see the changes of the buffer size.