In a tree with editable cells and fixed height rows, the row height is (and has been) set to the height needed to display an edit or combo box control. In other cases (variable height rows or no editable cells), the row height is typically less. This has caused unhappiness from various parties, for two reasons:
| • | In the case of editable cells with variable height rows (XTF_VARY + XTF_EDITABLE), the rows start out short but then change height when a cell is edited on that row. (I've argued that this is a "feature" not a bug, but with decidedly poor results.) |
| • | In the case of non-editable trees with fixed height rows, the row height doesn't match the equivalent tree with editable cells. (This is hard to label a "feature", but it is debatable whether it is a bug.) |
To "fix" these "problems" without breaking existing properly-written programs, XTREE now allows you to set XTR'ITEMLINES to 0, producing the same effect as 1 except that the row height in both of the above cases will be set to match the edit/combo control height (in other words, to match the height of editable trees with fixed height rows).
Warning: there is a slight compatibility concern here. Even though the effect of setting XTR'ITEMLINES=0 was not previously defined, in practice, it acted like XTR'ITEMLINES=1. The XTREE row height in such programs may be increased when installing this patch. (Although we try to avoid this kind of situation, especially in the "stable" release, in this case, the change is subtle enough, and purely aesthetic, and only affecting programs that were not coded according to the documentation, that it seemed harmless.)
