Author | Message | Time |
---|---|---|
Grok | Given a populated ListBox, I'd like to delete the blank lines. [code] Dim lRet As Long, lPos As Long Dim strSearch As String strSearch = "" lRet = SendMessage(List1.hwnd, LB_FINDSTRING, -1, ByVal strSearch) If lRet = LB_ERR Then Exit Sub lPos = lRet lRet = SendMessage(List1.hwnd, LB_DELETESTRING, lPos, 0)[/code] However, after LB_FINDSTRING, lRet is always -1, no matter how many blank lines are in the listbox. If I search for any string with strlen>0, the search succeeds. What is the correct solution for finding blank lines in a listbox? | June 30, 2003, 1:56 PM |
Kp | [quote author=Grok link=board=5;threadid=1746;start=0#msg13293 date=1056981372] Given a populated ListBox, I'd like to delete the blank lines. [code] Dim lRet As Long, lPos As Long Dim strSearch As String strSearch = "" lRet = SendMessage(List1.hwnd, LB_FINDSTRING, -1, ByVal strSearch) If lRet = LB_ERR Then Exit Sub lPos = lRet lRet = SendMessage(List1.hwnd, LB_DELETESTRING, lPos, 0)[/code] However, after LB_FINDSTRING, lRet is always -1, no matter how many blank lines are in the listbox. If I search for any string with strlen>0, the search succeeds. What is the correct solution for finding blank lines in a listbox? [/quote]I note that you're doing "ByVal strSearch" in the SendMessage call. I may be wrong, but that sounds like it would pass the wrong data. According to LB_FINDSTRING documentation, the last paramater is a pointer to the string for which to search - so maybe ByRef would be more appropriate? | June 30, 2003, 6:12 PM |
Camel | [quote author=Kp link=board=5;threadid=1746;start=0#msg13327 date=1056996765] [quote author=Grok link=board=5;threadid=1746;start=0#msg13293 date=1056981372] Given a populated ListBox, I'd like to delete the blank lines. [code] Dim lRet As Long, lPos As Long Dim strSearch As String strSearch = "" lRet = SendMessage(List1.hwnd, LB_FINDSTRING, -1, ByVal strSearch) If lRet = LB_ERR Then Exit Sub lPos = lRet lRet = SendMessage(List1.hwnd, LB_DELETESTRING, lPos, 0)[/code] However, after LB_FINDSTRING, lRet is always -1, no matter how many blank lines are in the listbox. If I search for any string with strlen>0, the search succeeds. What is the correct solution for finding blank lines in a listbox? [/quote]I note that you're doing "ByVal strSearch" in the SendMessage call. I may be wrong, but that sounds like it would pass the wrong data. According to LB_FINDSTRING documentation, the last paramater is a pointer to the string for which to search - so maybe ByRef would be more appropriate? [/quote] It depends on how you've declared SendMessage IIRC. If you have the third param declared as "As Any" or "As String", it will be converted to a pointer automaticly. My suggestion is to declare it "As Long" and use the StrPtr([String]) function to get a pointer to your string for clarity's sake. But to answer your question Grok, I'm pretty sure you just need to change your -1 to 0, because VB isn't zero-based. | June 30, 2003, 11:16 PM |
Grok | [quote author=Camel link=board=5;threadid=1746;start=0#msg13355 date=1057014983] But to answer your question Grok, I'm pretty sure you just need to change your -1 to 0, because VB isn't zero-based.[/quote] The -1 tells LB_FINDSTRING where to begin the search after. If I used 0, the search would begin after the first entry. MSDN on LB_FINDSTRING says to use -1 to begin search with the first element of the ListBox. Note to Kp: The same code finds non-blank entries just great. It is only when I search for an empty string that the search fails to find the targets. Thanks to both of you but this remains unsolved. | July 1, 2003, 8:25 AM |
Zonker | You could always send a LB_GETTEXTLEN msg for each of the items and see if they return 0 | July 1, 2003, 9:46 AM |
Adron | [quote] LB_FINDSTRING An application sends an LB_FINDSTRING message to find the first string in a list box that begins with the specified string. [/quote] What string doesn't begin with an empty string? I.e. it doesn't make any sense at all to give it an empty string. Try LB_FINDSTRINGEXACT instead. | July 2, 2003, 9:09 PM |