ListBox.ListCount

While playing with this recursive directory search in the other thread I came upon something I never noticed in about ten years VB6 experience, and wanted to ask if someone knows it too, and can probably mention a remedy:

Put a ListBox on a Form and in Form_Load() fil it with 32000 items.
After that Debug.Print List1.ListCount. Looks good.
Now fill it with 40000 items and you get printed -25536 which, as is obvious, is the representation of 40000 as a signed 16bit integer.

More weird is the fact that the ListBox can easily accept more than 200000 items, but the .ListCount property always is within the signed 16 bit range.
This seems to make the .ListCount property worthless as soon you expect more than 32767 entries in a ListBox.

Anyone knows this phenomenon, or even better has a patch for it?

Sure. It's a built-in limit. Can only address 32K items

I get an error if I try to add more than 32767 items.

That's interesting. And funny. How do you add items, Wiz?
I can add 500000 (half a million) items no problem and no error. And the items are really there, visible in the list.

Quote:

---

Originally Posted by WoF

That's interesting. And funny. How do you add items, Wiz?
I can add 500000 (half a million) items no problem and no error. And the items are really there, visible in the list.

---

Using the AddItem method, of course.

I do:

Code:

---

Dim i&
For i=1 To 500000: List1.AddItem Format(i, "000000"): Next

---

without any problem or error.
Only afterwards the .ListCount property behaves as I have described before.

That is odd. I have no idea how you could add that many items to the list without an error [bug in list box?] I wonder what would happen if you try to access the selected item when that item is deeper than 32k into the list?

I just added 100k items to a listbox when I select the last item the text property returns the data selected. The List index property was around -31k

Yes, i just tried too. The .Text property returns the selected item. ListIndex is, however, as scrambled as ListCount, like signed 16bit quantity.
Accessing elements with an index above 32767 is impossible though.
Print List1.List(50000) produces an overflow error.

I think that's really weird.
The ListBox accepts so many elements and does not allow to count or retrieve them.

Simple... ;)

Tells me David is 8642001

Code:

---

Option Explicit

Private Sub Combo1_Click()
  Dim msg As String
'  MsgBox Combo1.Text
  msg = Combo1.ItemData(Combo1.ListIndex) & " "
  msg = msg & Combo1.List(Combo1.ListIndex)
  MsgBox msg
End Sub

Private Sub Form_Load()
  ' Could also use ' List1.ItemData(0) = 5
  List1.AddItem "David G"
  List1.ItemData(List1.NewIndex) = 8642001 ' New Index
  List1.AddItem "Greg G"
  List1.ItemData(List1.NewIndex) = 8642000 ' New Index
  Combo1.AddItem "David G"
  Combo1.ItemData(Combo1.NewIndex) = 42001 ' New Index
  Combo1.AddItem "Greg G"
  Combo1.ItemData(Combo1.NewIndex) = 42000 ' New Index

End Sub

Private Sub List1_Click()
' Append Name to ItemData
  Dim msg As String
' msgbox list1.text
  msg = List1.ItemData(List1.ListIndex) & " "
  msg = msg & List1.List(List1.ListIndex)
  MsgBox msg
End Sub

---

Sorry, I don't quite get what it is you want to say with that code.

Nor do I, Only 2 items in the list and the number is hard coded into item data, naturally it will return what you coded into it.

Well, if you add a million items, in order, then they'd return the index in order.

EDIT: Then there's the Net Framework...

return the index?

the index is no longer valid once it exceeds the bounds allowed. Sure if you set the item data to the number which should be the index and someone clicks on that item you could get that number for all the good it would do you.

You can't reference the listindex or list1.list(x) or listcount once it exceeds the bounds so I fail to see what the fact that you can add somthing larger into itemdata actually would be useful for in this case.

Just use an array() and adjust the lower and upper bounds to that of the listbox

Might the installation of some other programs such as .net have something to do with being able to add so many items without the error?

Perhaps. I do have VS.net 2005 on the system I tested on

Quote:

---

Just use an array() and adjust the lower and upper bounds to that of the listbox

---

Why bother to use the list box at all? After all it is not designed to hold that many items and is rather slow to boot. I can't think of anyone who would actually want to scroll through a million items or for that matter even 32k items.

Both the combo box and list box were created back in the 16 bit world of ancient times past, hence the limit on being able to access items over vb's max integer value but in theory, you can add 2^31-1 entries but you would more than likely run out of memory long before you reached that limit.

Okay, time for TMI (Too much information). The additem method is a wrapper for the LB_ADDSTRING message and the wrapper does not impose a limit check but relies on the underlying control, so you are able to add these large amounts of data that eventually, you will not be able to access. Because, ListCount, ListIndex, TopIndex, NewIndex, RemoveItem, and the List Property only accept vb's signed integer as a value.

Also: As a side note, going back to the other thread, using sendmessage with the LB_ADDSTRING message will speed up the loading of the listbox...



Good Luck

This very strange indeed! :confused:

I managed to get 500000 items to my listbox, as per attached picture ( ListBox ). It took just about a minute to load!

What is really freaky is that when I do this :

Code:

---

Private Sub Command2_Click()
Form1.Caption = List1.List(List1.ListIndex)
End Sub

---

The form's caption turns into an empty string. I clicked on items randomly, sometimes nothing shows up sometimes, but the next item in the list shows the Hex value.

Better explained: If I click on an item, it doesn't show, when I click on an item Just beneath the previous one, it shows the hex value

I doubt that it has something to do with the .NET Framework. I have .NET Framework 1.1, 2.0, 3.0, 3.5 as well as 4.0 on my system. The reason why I say so is when I do this in .NET :

Code:

---

    Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Dim i&
        For i = 1 To 500000 : ListBox1.Items.Add(Format(i, "000000")) : Next

    End Sub


    Private Sub Button2_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button2.Click
        Me.Text = ListBox1.SelectedIndex

    End Sub

---

which is the same as this VB 6 code :

Code:

---

Private Sub Command1_Click()
Dim i&
For i = 1 To 500000: List1.AddItem Format(i, "000000"): Next
End Sub

Private Sub Command2_Click()
Form1.Caption = List1.List(List1.ListIndex)
End Sub

---

It also takes about a minute to load the list, BUT, it gives me the correct info, as per attached picture ( ListBoxVBNET ).

Well, perhaps it may be due to the .NET Framework, I don't know, why I'm thinking that now is that if people without any .NET Framework gets errors when attempting to add 500000 items to the list, and people with .NET Framework doesn't get errors. Perhaps it is VB 6's limited built in capability?? Perhaps the "new" listbox ( bundled with the Common Controls ) is working properly, but VB 6 cannot handle it?

Then I'm thinking it could be a Service Pack issue, but I doubt...

Strange ....

I hope you understand what I wrote.... :)

Quote:

---

Originally Posted by vb5prgrmr

Both the combo box and list box were created back in the 16 bit world of ancient times past, hence the limit on being able to access items over vb's max integer value but in theory, you can add 2^31-1 entries but you would more than likely run out of memory long before you reached that limit.

Okay, time for TMI (Too much information). The additem method is a wrapper for the LB_ADDSTRING message and the wrapper does not impose a limit check but relies on the underlying control, so you are able to add these large amounts of data that eventually, you will not be able to access. Because, ListCount, ListIndex, TopIndex, NewIndex, RemoveItem, and the List Property only accept vb's signed integer as a value.

Also: As a side note, going back to the other thread, using sendmessage with the LB_ADDSTRING message will speed up the loading of the listbox...

Good Luck

---

Looks like the whole VB Control is a Wrapper for the control provided with Windows. And this should be 32bit (XP an higher)

Try LB_GETCOUNT using the hWnd from the VB Control.
(LCount = SendMessageLong(ListBoxControl.hWnd, LB_GETCOUNT, 0, 0)

Should get you the correct amount of items in the list.

Yes, using SendMessage seems to be a good idea and possibly the only useful way to skip the integer wrappers of the VB ListBox control. I'm sure there is a LB_GETSTRING and REMOVESTRING message, too. Have to look this up...

It seems in VB.NET other wrapper classes provide correct 32bit properties.

Like this:

'// SendMessage returns Index of SelectedItem
lpIndex = SendMessageLong(mHlp_hWnd, LB_GETCARETINDEX, 0, 0)
'// Initialise String Var with 1024 Byte
cTemp = Space(1024)
'// SendMessage returns length of returned String
LRes = SendMessageStr(mHlp_hWnd, LB_GETTEXT, lpIndex, cTemp)
'// now reduce the string to actual textsize
cListText = Mid$(cTemp, 1, LRes)

Gets Text of Selected Item.