Dynamic Buffer for GetWindowText

[Gary Domantay]

Hi Guys,

I'm using SDK controls for my program, and i'm changing 'CONTROL GET TEXT' with GetWindowText but instead of using ASCIIZ buffer, I want to use a dynamic string. Reason is that i'm not sure with the length in characters of the strings. Is there any problem with the code below?

txtLen=SendMessage(GETDLGITEM(hWnd, Ctrl_ID), %WM_GETTEXTLENGTH, 0, 0)

LOCAL txtBuffer AS STRING
txtBuffer=STRING$(txtLen + 1,$NUL)

GetWindowText GETDLGITEM(hWnd, Ctrl_ID), BYVAL STRPTR(txtBuffer), txtLen + 1

txtBuffer=LEFT$(txtBuffer, txtLen)

I've tested it and so far it works without any problems.

Many Thanks

-Gary-

[Dominic Mitchell]

Its OK, but to make this line useful

txtBuffer=LEFT$(txtBuffer, txtLen)

do this

textLen = GetWindowText(GETDLGITEM(hWnd, Ctrl_ID), BYVAL STRPTR(txtBuffer), txtLen + 1)

Because under certain conditions, the DefWindowProc function returns a value that
is larger than the actual length of the text. GetWindowText returns the actual length of
the text.

[Michael Mattias]

GetWindowTextLength() anyone?

[Dominic Mitchell]

GetWindowTextLength() anyone?

Has the same caveat as WM_GETTEXTLENGTH.

[Michael Mattias]

What caveat? You put a caveat on return from DefWindowProc, not either WM_GETTEXTLENGTH or GetWindowTextLength().

But let's assume that's just a typo or semantic thing.

The question which follow is pretty straight-up: Where is said caveat documented?

My doc says both WM_GETTEXTLENGTH and GetWindowTextLength() return number of tChar not including terminating null.

I searched MSDN for all WM_GETTEXTLENGTH and found nothing that looks like either a bug report or a caveat.

????

MCM

[Dominic Mitchell]

What bug? There is no bug.

The caveat is related to this part of his original code

txtBuffer=LEFT$(txtBuffer, txtLen)

which made no sense without my modification to trap the return value from WM_GETTEXT.

I never use GetWindowTextLength or WM_GETTEXTLENGTH to determine the actual length of the text.
I use them to allocate the size of the buffer that will receive the text. The actual length
of the text is returned by GetWindowText or WM_GETTEXT.
This is clearly spelled out in the docs.

Under certain conditions, the GetWindowTextLength function may return a value that is larger
than the actual length of the text. This occurs with certain mixtures of ANSI and Unicode, and
is due to the system allowing for the possible existence of double-byte character set (DBCS)
characters within the text. The return value, however, will always be at least as large as the
actual length of the text; you can thus always use it to guide buffer allocation. This behavior
can occur when an application uses both ANSI functions and common dialogs, which use Unicode. It
can also occur when an application uses the ANSI version of GetWindowTextLength with a window whose
window procedure is Unicode, or the Unicode version of GetWindowTextLength with a window whose window
procedure is ANSI. For more information on ANSI and ANSI functions, see Conventions for Function Prototypes.

To obtain the exact length of the text, use the WM_GETTEXT, LB_GETTEXT, or CB_GETLBTEXT messages,
or the GetWindowText function.

[Michael Mattias]

I have that caution (verbatim) right in my doc in the GetWindowTextLength function.

I guess you need to click toward the bottom of that scroll-bar thingee on the right to see all the "Remarks".

My bad.