Hi folks,

I'm have a user-control that imitates a thumbnail-listview. Within, I have
a panel (pnlOuter) that represents the viewable area and another panel
(pnlInner) which represents the list as a whole with a scrollbar that'll
enable the user to change the viewable area.
Hence, pnlInner will grow in vertical size once more items are added to the
list than may fit into pnlOuter (being the viewable area).

When checking the behaviour with a large list of items though I had to find
out that a panel's height may not exceed 32767 pixels (= int16.MaxValue).
No exception will be risen, but the control just won't grow anymore.
Thus, if any items are added that would require pnlInner to be larger than
this max-value, they may never be seen/scrolled to.
The same also applies to a user-control itself - no way to enlarge it above
32767px!

Is there any way to further enlarge a control? Virtually, the panel would
have to be able to have an infinite height really, but I guess it'd be more
probable that there'd be insufficient memory first.
How would I have to handle resp. create such a large listbox in general?
From Access I know the fact that there may not be more than 65535 items at
a time - is that really connected to the listbox's max. height?

Thanks for any suggestions!

Cheers,
Olaf

Olaf,

No, there is no way to increase this limit. It is a limit of the operating
system itself, not just .NET.
However, if you do the math, you will find that even without increasing the
dimensions more you can exceed the memory limit of windows itself. Between
2-4GB for just one control. Before you do all the other things you need to.

When someone asks a question about limits, it is usually due to a
methodology that simply won't work on the proposed scale. This applies here
as well. IMHO, even if you could expand the virtual size of the control and
fill it up, you shouldn't. You should implement a methodology of displaying
only the thumbnails required for the proposed view. It will probably mean
managing the scroll bars as well. To represent where you "should" be in the
list, then only load and display the thumbnails that need to be in the view.

If you think about it in those terms, the panel itself would only "need" to
be actual size. However, I could see where for your convenience you might
want to make it bigger, but only slightly. Basically, only larger by 1 row
of thumbnails.

Hope that made some sense.

Gerald


Show quoteHide quote

Hi,

Gerald Hernandez wrote:

sure did - thanks! I know I could've done that, but I'm wondering about how
to actually implement that. I guess there'll be lots of implications
concerning speed during scrolling as the items within the list would have
to be rearranged constantly. Also, if I don't have all items in memory, I
would be forced to load the thumbnails while scrolling - that would consume
way too much time as the thumbnails would either have to move from one item
to another or the visible ones would have to be repositioned all the time.
I wonder how this is implemented in Windows resp. WinExplorer itself - it's
blindingly fast and there's just no flickering. Also, although thumbnails
seem to be loaded when you scroll through a large thumbnail-list in
WinExplorer, the items will be there pretty quick, but the thumbnail-images
may come later. But that's limited to "the first view". Once shown, they'll
be there without them having to be loaded again.

That said, I'm not really trying to implement the best, but the fastest way
really. In terms of memory, I had some 2000 items within the list with a
memory-peak below 100MB for the app as a whole. Since my app will be the
only one running on target-systems, that would be just fine ...

Thanks,
Olaf

As I'm sure you figured out, this could be from mildly to very complicated.
You will certainly want to build a thumbnail cache instead of generating
each on the fly and/or discarding them.
If it were me, I'd implement a grid type system.
Determine all the thumbnails you will need up front, then break them into
rows and columns based on the window width and thumbnail width.
Then as part of the cache item, prop it as to whether the thumbnail is valid
yet or not. You could even push a temporary image in there that could be
shown while the thumbnail is being generated, then pop the full image in
it's place when it's done. Kind of Explorer like.
Then build all the thumbnails you need for the current grid items, plus a
small buffer, maybe only 1 row on each side.
Display those. Now you could launch a background thread that continues
building the remaining thumbnails. Hopefully, the user will take a few
moments to look at the thumbnails, giving your background thread time to do
it's job.

Now that you have a grid system, determining your parameters for the scroll
bar is pretty easy. Also, determining which rows should currently be
displayed is pretty easy.

As far as actually scrolling, you could use the chunky method, where each
scroll tick would scroll one entire row. Not the most elegant, but easy to
code. But in the end, you will probably want smooth scrolling. This is when
I would make the panel area larger by one row on each side. When you scroll,
if you are not on a full row boundary, just scroll by the proportion of the
off-screen row you want. When you hit the row boundary, just tick up the
current row counter and redraw them all. If done properly, it will be smooth
and seamless to the user.

Of course, this is just one of many ways it could be done, but I think it
would be a good compromise between speed and memory usage. You are only
displaying and scrolling what you actually need to. Plus, you would have the
full cache of thumbnails available as well.

Gerald

Show quoteHide quote

Loop ?
Binding an Array to a Combo Box
SqlDataReader accessed only by field ordinals?
Singleton Pattern for Database Access --- Leave Open or Close Connection
How to update an application
Finding Version of All Asemblies Required by Application
How to Publish a Project to Production Server
special character inside a string
Category does not exist?
repainting problem