Announcement

Collapse
No announcement yet.

Dynamic Buffer for GetWindowText

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Michael Mattias
    replied


    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.

    Leave a comment:


  • Dominic Mitchell
    replied
    What bug? There is no bug.

    The caveat is related to this part of his original code
    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.

    Leave a comment:


  • Michael Mattias
    replied
    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

    Leave a comment:


  • Dominic Mitchell
    replied
    GetWindowTextLength() anyone?
    Has the same caveat as WM_GETTEXTLENGTH.

    Leave a comment:


  • Michael Mattias
    replied
    GetWindowTextLength() anyone?

    Leave a comment:


  • Dominic Mitchell
    replied
    Its OK, but to make this line useful
    Code:
    txtBuffer=LEFT$(txtBuffer, txtLen)
    do this
    Code:
    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.

    Leave a comment:


  • Gary Domantay
    started a topic Dynamic Buffer for GetWindowText

    Dynamic Buffer for GetWindowText

    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?

    Code:
    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-
    Last edited by Gary Domantay; 9 Apr 2008, 10:26 PM.
Working...
X