No announcement yet.

Large virtual listboxes

  • Filter
  • Time
  • Show
Clear All
new posts

    Large virtual listboxes

    Guys --
    I have 6 different array (5000-10000 rows).
    In any current moment I need to display one only and is able to do common DlgProc.

    But I worry about performance. To switch to another array I need 10000-20000 SendMessage (ADDSTRING + SETITEMHEIGHT per each row).
    Not a problem for my PC, but not sure in customers PCes.

    So, what's better - to have 6 independent listbox or 20000 SendMessage works enough fast even on old PC(something like 200-300 MHz, 32 RAM, Windows 95/98).

    E-MAIL: [email protected]


    If you only need to display one at a time, do you need to use a list box
    at all ? Could you do it be just displaying the member of the array you
    needed without having to fill the list box at all, it sure would be a lot
    faster if that is what you were after.


    [email protected]

    hutch at movsd dot com
    The MASM Forum - SLL Modules and PB Libraries


      Well, guess you know what my answer will be: You already have the
      arrays, so use a virtual listbox like the one I once posted and Jules
      later has updated..

      In a test app here, I load up to 14 language databases with between
      20,000 and 140,000 items each, after which I can switch between them
      instantly, using %VLB_SETARRAY and %VLB_REFRESH.

      Another approach: use ownerdrawn listbox and in WM_DRAWITEM grab the
      text directly from the arrays. Since you use SETITEMHEIGHT, I guess
      you are using similar listbox like the samples you posted a while ago
      (loved them), so what about just using the listbox as an "empty shell"
      for the arrays like that? Should be very fast.

      Do you really need to use SETITEMHEIGHT on all items? Isn't it enough
      to do this for visible items only, inside WM_DRAWITEM?



        Steve --
        I meant one array.

        I need to show a list of cargoes (international NHM or internal 'NHM'), or a list of stations.
        Any list could be in numeric or alphabetic order.

        Each line hase different height (there are very long names and I draw them as some lines on the screen - similar like in books).

        When user searches an item, he should have, for example, a possibility to switch numeric/alphabetic order.
        I already realized these lists in MS-DOS program (it was very fast), in VB program - it was also enough fast, but a price was "too high".
        I used small MSFlexGrid (20-30 lines, 5-6 columns) and wrote a lot of code (I changed values in table).

        Just now I have a big wish to avoid stupid work (anyway I can't translate VB code 1 to 1, because I changed data sets).

        E-MAIL: [email protected]


          After-thought: Remember that each standard listbox will more than double the
          memory needs for each array. 10,000 items should mean at least 80 KB extra
          each, using empty strings (space for string pointers and item data). If to
          add the strings too, well..

          Real Virtual listbox use already existing arrays and nothing more..



            Borje --
            Virtual listboxes ... I saw your code. Unf., too large.
            Of course, I use non-own code, but always try to understand/reconstruct it to my needs.

            Actually, I struggle with myself - to use "old" approach (in MS-DOS and VB it took about 1000-1500 statements) or to use a new (yes, ownerdrawn listboxes w/o strings).
            Old way (sure) will work very fast (100 Textout to update a screen).
            Advantage of another - not necessary to process scrolling messages by myself.

            Oh ... Time to accept a decision. I'll look your code tonight.
            Probably, I'll "import" ideas (hope, it's "multiline" ?).

            E-MAIL: [email protected]


              Hm, not multi-line, sorry, but easily fixed in WM_PAINT. Another though
              that may be even nicer approach - use a virtual ListView! No need for
              multi-line there. If line is too long, popup label will show the rest
              of it and you get columns ready for sorting, etc. A more consistent
              look and feel that way.

              Have a filefind sample based on code from Roberto Valois that shows
              a way of using it. Very fast, with sorting by columns and all: See

              Or download directly: (25KB)



                Borje --
                I thought and decided to use old way (means completely ownerdrawn - something like your virtual listbox).
                I looked your code a little and noticed that you use "static" hMemDC & hMemBmp to avoid Create ... in each WM_PAINT.
                This confused me a little.
                Do you have reasons to think that these API functions require a lot of time ?
                I ask, because a size of hMemBmp could be enough serious, at least, in my case (1-2MB, depends of resolution).

                E-MAIL: [email protected]


                  More fun to write all from start and get complete control. A while since I
                  wrote that one. Not sure code is 100% correct, but know you can see eventual

                  One advantage of keeping a static DC is when you do line by line scroll.
                  Then it's possible to bitblt from static DC up/down one line and then
                  only redraw the new line that becomes visible. Makes single line scroll
                  much faster. Otherwise, think no difference in speed by using static
                  versus locally created on the fly.

                  One strange thing about static memDC's I never have been able to figure
                  out is that sometimes bitblt'ing (scrolling) suddenly can slow down a bit.
                  Then suddenly speed is back to normal again - ususally if I do full page
                  scroll, which creates totally new memDC.

                  Has made me think a device context can become fragmented after a while.
                  Maybe not possible, but that is the only explanation I can think of.