CB_FindStringExact

[Peter Lameijn]

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 (?)

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

[Michael Mattias]

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..

           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

[Peter Lameijn]

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...

[Jeff Blakeney]

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:

#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)).

[Michael Mattias]

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.

[Jeff Blakeney]

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.

[Michael Mattias]

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:

 szAsciizVar = "Hello"

... results in the buffer being Hello<nul>???????? ==> SIZEOF(szAsciizVar)

Whereas...

   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