Stormwolf

I've been tasked with updating a VB6 app that was written by someone else a couple of years ago. The purpose of the application is to produce a 'diff' report on a hierarchical object model (as a CASE tool plug in).

My problem is that the difference between the models have now grown to a magnitude where the number of items reported now exceeds the limits of the VB Listbox (given that if you try to contain more than 32767 items the Listbox.ListCount property returns a negative number and screws up a number of further operations).

Given that I'm not a VB programmer (I've spent years avoiding anything with a GUI) and my manager isn't prepared to allow the time to rewrite the whole application, what strategies would you suggest for dealing with the issue?

So far I have:

• Cap the list at 32767 entries. Further changes are lost
• Divide up the list results into a variable number of 'list pages'
• Split the results into 'adds, deletes and changes and display each in a separate list (this might still hit cap issues in some situations)

I'm not sure that a tree view is a good idea for performance reasons given the size of the dataset. Any more suggestions on what to do with this apart from curse Microsoft for not thinking beyond the limits of a 16-bit integer?

NB Any suggestions need to be VB6-compatible (unfortunately)

h33b

Although I have only just started taking courses in VB, I have to ask which version of Visual Studio are you using? I've never had that many list box items, but it seems like it might be a limitation in an earlier version of the studio. I know that in class we had incompatibilities in editing between the 2003? and 2008 versions, though through compiling issues were removed.

Just my .02

__________________
My lapped q6600 and Tuniq Tower
Folding for OCN
Killed my first motherboard due to overclock on 5/17/08 - I'll miss you P5N-E SLI

Stormwolf

As I said, it's Visual Basic 6. Unfortunately. I'm restricted in what I can use here for various reasons... VB.NET (i.e. Visual Studio 2003, 2005, or 2008) solutions are not an option

Nice sig pic btw

linskingdom

Technically, you can add more than 32767 items (int16) to the listbox but just can’t access the items beyond 32767. To work around this, if you can, you can use control such as listveiw to take advantage of 16bit Long data type but the appreance is different than listbox.

__________________
Push the limit one more time...

Intel Penryn (45nm) Thread|GeForce 9 Series GPU Thread|Intel E1xxx/E2xxx Configuration Thread
8800GT Information Thread|VMark Beta Testing Thread|GeForce GTX200 GPU Thread

The_Rocker

After you have reached 32767 items, store the whole range of data in a variable or even write to a file if you must. Then recall the information into the listbox control source.

This way you could have multiple "sets" of data and call each one up when needed.

The only problem here is that you may as well be rebuilding the entire app and in that case you may as well use 16bit controls and data types to store the information.

Stormwolf

I know you can add more than 32767 entries (because that's what I did without any VB complaining at all As you say, the issue comes out when you actually try to display beyond the limit. The scroll bar also caps out at 32767) and (as far as I can work out) the Listview also has a limit of 32767 entries.

The results are already in an internal data structure (effectively a paired array parsed directly from the CASE tool model) - the original problem was that the guy who implemented the tool used static arrays, which caused the tool to fall over when you exceeded the array limit. I fixed this problem, only to reveal the UI issue.

I think I'll probably go for the page's approach (effectively a 'window on the list' and display a couple of hundred at a time, with maybe a filter on top to further limit the display to items of interest.

linskingdom

The page's approach is a good solution. It works much better and may speed up the whole thing. Also, to use offline ADO data storage is another work around. Good luck.

__________________
Push the limit one more time...

Intel Penryn (45nm) Thread|GeForce 9 Series GPU Thread|Intel E1xxx/E2xxx Configuration Thread
8800GT Information Thread|VMark Beta Testing Thread|GeForce GTX200 GPU Thread

Stormwolf

It'll certainly speed up the report generation stage which currently gives a good impression of a hung app ADO data storage is beyond the scope of this app, which is really just a difference reporting tool. The models are already stored in their own database.