LV listbox size limitation

[wd]

Is there a limitation to the number of entries a listbox will display? My attached program indicates there is. If you run it, I can only scroll through to 32767 items. Ultimately, I want a program I can list a directory of files(80000+) and allow the user to multi-select for further operations. I experienced this limit with that program in development... so I put the attached program together to confirm the same limitation. I know I can develop an alternate method, but I would like to just use the tools(listbox) provided.

Thanks.

[Don_Phillips]

Yes, this is the max limit for a standard ListBox control. It is not enforced by LabVIEW however. This is the hard limit coded by MicroSoft for this particular control 😃

Sorry for the bad news...

[rolfk]

Maelstrom wrote:

> Yes, this is the max limit for a standard ListBox control. It is not enforced by
> LabVIEW however. This is the hard limit coded by MicroSoft for this particular
> control 😃

Well, unless you talk about the Active X list box control, the built in
list box control in LabVIEW has nothing to do with the Microsoft
control. It really couldn't as the same control needs to be implemented
on all other LabVIEW plattforms in a consistent manner. So if there is a
limit it is imposed by LabVIEW in fact although this limit may have
been inspired by the implementation in Windows.

On second thought think about the memory requirements for a listbox
control with more than 32000 entries. Each entry needs at least 16 bytes
plus some extra information such as font settings, color settings etc,
plus the actual string information. Such a control is getting a memory
manager nightmare in no time.

Rolf Kalbermatter

[rolfk]

Maelstrom wrote:

> Yes, this is the max limit for a standard ListBox control.

To add to this, I just tried to read the string array back and got to
full number of elements from it. So the list box does not really limit
the number of elements (well it does as the index is of course an int32
but 2 billion lines should be still many years before any hardware
system could even get close in managing the necessary memory for this.

So it seems the limit is actually in the scrollbar of the list box.
Strange enough if I set the Top Row property to lets say 30000 I see the
scrollbar thumb jump to the appropriate relative position but when you
operate the thumb it jum ps back to the virtual 32000 elements limit.

Warning: Don't set the Top Row property above ~32767 as this will crash
LabVIEW.

This definitely is a bug in the LabVIEW scroll bar implementation.

Rolf Kalbermatter

[Don_Phillips]

> Well, unless you talk about the Active X list box control, the built in
> list box control in LabVIEW has nothing to do with the Microsoft
> control. It really couldn't as the same control needs to be implemented
> on all other LabVIEW plattforms in a consistent manner. So if there is a
> limit it is imposed by LabVIEW in fact although this limit may have
> been inspired by the implementation in Windows.

If it runs on Windows it is (ultimately) a standard Windows control. The
consistancy is via an abstraction layer. Case in point LabVIEW for Mac
looks just the same (or nearly) as LabVIEW for Windows and yet Mac does
not have ActiveX support.

> So it seems the limit is actually in the scrollbar of the list box.
> Strange enough if I set the Top Row property to lets say 30000 I see the
> scrollbar thumb jump to the appropriate relative position but when you
> operate the thumb it jum ps back to the virtual 32000 elements limit.

Yeah well. I did not really want to dredge into the details but yes,
the actual problem is with the Windows ScrollBar control. Its not just
the ListBox as you might well imagine. Most Windows controls which use
a *standard* scrollbar will have the same issue. Some controls implement
thier own custom scrollbar internally and these can access up to 4 gigs
but these are far and few between.

[wd]

Thanks for your replies! Very informative... if one has a suggestion on how I might develop a work around... I would appreciate that too! I've been working since my initial post and have yet come up with a clean solution.

[rolfk]

Maelstrom wrote:

> If it runs on Windows it is (ultimately) a standard Windows control.
> The consistancy is via an abstraction layer. Case in point LabVIEW
> for Mac looks just the same (or nearly) as LabVIEW for Windows and
> yet Mac does not have ActiveX support.

Well, I didn't say it was an Acitve X control, only that IF you are not
talking about an Active X control, that it is completely a LabVIEW
control not relying on any control implementation in the Windows
standard controls.

I can assure you that LabVIEW controls are ENTIRELY implemented by
LabVIEW and do not use any Windows standard controls in any way. LabVIEW
goes however to the extend to try to imitate the look and feel of the
native platform controls if you use the so called dialog controls but
that is a complete LabVIEW implementation.

>Yeah well. I did not really want to dredge into the details but yes,
>the actual problem is with the Windows ScrollBar control. Its not just
>the ListBox as you might well imagine. Most Windows controls which use
>a *standard* scrollbar will have the same issue. Some controls implement
>thier own custom scrollbar internally and these can access up to 4 gigs
>but these are far and few between.

I'm pretty sure even the scroll bar is a complete LabVIEW
implementation. It would be strange to implement all other controls
completely in LabVIEW (and believe me they are) and only import the
sroll bar from the Windows standard controls. A simple check on non
Windows systems would show if the list box can handle more than 32000
elements there. I really doubt it.

Rolf Kalbermatter

[johnsold]

It crashes LV on Mac OS X at 32767 also.

Lynn

[rolfk]

johnsold wrote:
> It crashes LV on Mac OS X at 32767 also.

Yes! It seems the Listbox control uses internally an int16 for the
TopRow value, eventhough the according property node uses an int32. Bad,
bad, bad!!!

Rolf Kalbermatter

[Don_Phillips]

This might be sub-optimal, but I think you are limited in your options...

It should be possible to add an up/down control for indexing and maybe a read only index description. My idea would be to write to the listbox in 30k data item chunks. Have a hidden (or not) integer control which starts at zero. Multiply value in control by 30k to get the starting index into your large array set and load the listbox with 30k items. Use the up/down to change the indexing into the array. The read only description could be something like "Showing records: 30000 to 60000". And of course changing the index would remove all items from the listbox and reload the new values. Don't know how fast you can unload and load 30k items from a listbox so their might be performance issues...