> Also I saw a lot of scrollable things in Windows who were > longer than 32768 pixels (take big Excel tables, for example). > Maybe they are implemented in a different way.
I don't think that a big-grid GUI application like Excel will use controls for very much in its main window. Generally it is managing all that itself. It might use a _few_ plain windows, such as one for the column names on top, another for the row names on the left, and then a big one for the main grid client area. Just to make it easier to clip output. If the user clicks in a button-like area, it will handle that itself. e.g. If you click somewhere in the column header, it will calculate which column, and draw that column as selected. If the user clicks in a region it calculates to be a cell, it _might_ create a text-edit control there for in-place editing -- but just temporarily, and destroy it when editing finishes. All the logic for scrolling... managed itself. At least, that's how I did Windows GUI stuff like this, 15+ years ago. Usings hundreds or thousands of windows/controls was just too much overhead to get desirable speed and space. Although the overhead might be less, now, I imagine if you want a really crisp UI it's probably much the same story. ____________________ Racket Users list: http://lists.racket-lang.org/users
