Panel-height greater Int16.MaxValue?

  • Thread starter Thread starter Olaf Rabbachin
  • Start date Start date
O

Olaf Rabbachin

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
 
Hi,

Gerald said:
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.
Click to expand...

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
 
Back
Top