Re: TreeView: set_fixed_height_mode v TREE_VIEW_COLUMN_FIXED

On Dec 27, 2009, at 11:14 PM, Dr. David Alan Gilbert wrote:
>> FIXED does not mean fully fixed; a FIXED column can be set to be resizable by the user of the program.
>> A solution for the future will be to sample the widths of a set of rows/columns.  This will be an additional mode, as it does not comply with the strict rules for AUTOSIZE/GROW_ONLY.
> The other way to look at this is instead of asserting when you find a
> colume that isn't marked fixed, then you just measure those rather than all cells.
> That way you don't need any new modes anywhere as far as the API is concerned.

This is an interesting idea, however to satisfy the current AUTOSIZE/GROW_ONLY property we would still have to scan the entire tree and measure those cells.  It is exactly the scanning of the entire tree for cell measurement (often referred to as validation) that the fixed height mode is looking to fully avoid.

>>> In this case there is a big treeview with a thousand rows or so,
>>> all the same height but where the width of at least one of the columns
>>> varies - this doesn't sound an uncommon situation, but is causing
>>> call backs for ~5000 data functions for every cell in the tree
>>> on every redraw.
>> On a redraw, only the data functions for cells that are visible on the screen should be called.  5000 calls to data functions seems unlikely to me.
> I'm not sure, but I think the problem is that until you've measured
> all the rows above you, then you can't be sure what it is that's
> currently visible.

I assume that the big tree view in this case does not have fixed height mode enabled.  The default behavior is then that there is an initial pass through the given model, measuring all cells.  All row heights will be known after that.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]