Announcement

Collapse
No announcement yet.

CB_FindStringExact

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

  • Michael Mattias
    replied
    I see now that they could be quite handy as you don't need to trim the extra spaces filled to the right of the string like you do with fixed length strings.
    Just watch out for your assignment statements:
    Code:
     szAsciizVar = "Hello"
    ... results in the buffer being Hello<nul>???????? ==> SIZEOF(szAsciizVar)

    Whereas...
    Code:
       FixedStringVar = "Hello"
    ... results in the buffer being Hello<sp><sp> ==> spaces up to SIZEOF(FixedStringVar)

    That is, when you assign to ASCIIZ, only the length of the source + 1 $NUL char of the target variable is affected and you cannot count on the contents beyond that null; but an assignment to a fixed-string variable acts like an LSET [USING $SPC].

    If you need to "null out" an ASCIIZ variable, use RESET.

    MCM

    Leave a comment:


  • Jeff Blakeney
    replied
    The memory buffer of an ASCIIZ string is a fixed size but the length returned by commands like LEN will vary and if the length varies then it isn't a fixed length.
    • LEN(dynamicString) varies from 0 to maxmimum length of a dynamic string.
      Memory buffer size varies as well.
    • LEN(ASCIIZstring) varies from 0 to the size that the string was defined as minus one (last character reserved for the null).
      Memory buffer size is fixed at the size the string was defined as.
    • LEN(fixedLengthString) is always the size that the string was defined as (in other words, the length is fixed at that size).
      Memory buffer size is fixed at the size the string was defined as.

    I always thought ASCIIZ strings acted just like fixed length strings as that is what the documentation said to think of them as. I see now that they could be quite handy as you don't need to trim the extra spaces filled to the right of the string like you do with fixed length strings.

    Sorry for hijacking the thread.

    Leave a comment:


  • Michael Mattias
    replied
    thinking about ASCIIZ strings as I always thought of them as being fixed length strings where the last character was always a null.
    They ARE fixed length, however what is "valid" is only that portion of that length up to the first $NUL. if you refer to an ASCIIZ string using any of the PB string operators, the compiler will silently convert to dynamic string, but will ignore anything after the first $NUL.

    Leave a comment:


  • Jeff Blakeney
    replied
    When I first looked at your code I thought szStr might be a problem. I assumed with that prefix that it was an ASCIIZ string. I then did some tests and discovered something today. The documentation for PBWin v9.01 says to think of ASCIIZ strings as fixed length strings but it turns out they should be thought of more as strings with a maximum length. Take the following code for example:

    Code:
    #COMPILE EXE
    #DIM ALL
    
    FUNCTION PBMAIN () AS LONG
    
        LOCAL szStr AS ASCIIZ * 10
        LOCAL sfStr AS STRING * 10
        
        MSGBOX USING$("szStr is # characters long." + $CRLF + "sfStr is # characters long.", LEN(szStr), LEN(sfStr))
    
        szStr = "1234567890"
        sfStr = "1234567890"
        MSGBOX USING$("szStr is # characters long." + $CRLF + "sfStr is # characters long.", LEN(szStr), LEN(sfStr))
        
    END FUNCTION
    The first message box returns lengths of 0 and 10 and the second message box returns lengths of 9 and 10. I guess I need to change my thinking about ASCIIZ strings as I always thought of them as being fixed length strings where the last character was always a null.

    Not that I need to worry about it much, I don't use ASCIIZ or fixed length strings unless I absolutely have to. I prefer to use dynamic strings all the time and make them the size required at run time (sText = SPACE$(lNumChars)) and append a null to the end of it if I have to (sText = sText + CHR$(0)).

    Leave a comment:


  • Peter Lameijn
    replied
    Thanks,

    I found the problem.

    At program startup, the data for various controls is loaded into a UDT array. Because that uses fixed strings, data loaded into the comboboxes was padded with spaces...

    Leave a comment:


  • Michael Mattias
    replied
    You must have something wrong in the code which is not shown, since I used CB_FINDSTRINGEXACT just yesterday afternoon and it worked just ducky.

    That or CONTROL GET TEXT is not returning what you think it is returning, or what is in the string list of the combobox is not what you think it is ...eg, extra trailing carriage return or line feed, something like that.

    Here's my code if it helps..
    Code:
               CASE %ID_CUST_NO_ADD
                                  ' this should only be enabled when there is text in the invoice number box.
                   ' this is now a combo box
                   ' will be triggered by <CR> when editing, too.
                     ' MSGBOX "Add customer
                     ' get handle to the invoice combobox
                     hCtrl = GetDlgItem(hWnd, %ID_CUST_NO)  ' should return the text
                     GetWindowText  hCtrl, szText, SIZEOF(szText)
                     IF lStrlen(szText) THEN
                         ' add to combobbox box OF NOT ALREADY IN THERE (no dups allowed!)
                         iRet = SendMessage (hCtrl, %CB_FINDSTRINGEXACT, -1&, BYREF szText)
                         IF iRet= %CB_ERR THEN   ' NOT FOUND
                                 SendMessage  hCtrl, %CB_ADDSTRING, %NULL, BYREF szText   ' wparam must=0 this message
                         ELSE  ' string already exists in list and cannot be added
                             MessageBeep  %MB_ICONHAND
                         END IF
    
                      END IF
                     ' in any event  restore focus to the combobox control and clear the box
                      SendMessage  hCtrl, %CB_SETCURSEL, -1&, %NULL
                      SetFocus hCtrl

    Leave a comment:


  • Peter Lameijn
    started a topic CB_FindStringExact

    CB_FindStringExact

    When the user leaves the edit field of a combo box, I want to set the selection to the entered text (if it matches),
    but for some reason CB_FINDSTRINGEXACT always returns CB_ERR (?)
    Code:
    If CbCtlMsg = %CBN_KillFocus Then
      Control Get Text hDlg, CbCtl To szStr
      Control Send CbHndl, CbCtl, %CB_FINDSTRINGEXACT, -1, VarPtr(szStr) To Result
      If Result <> %CB_ERR Then
        Control Send CbHndl, CbCtl, %CB_SETCURSEL, Result, 0
      End If
    End If
Working...
X