If you use the X or x column codes to force XTREE to exit to the application for the purposes of cell validation, then you probably want to be able to re-enter the XTREE with a minimum of overhead and visual distraction. Here are few tips to facilitate this:
| • | The XTR.TARGETROW and XTR.TARGETCOL parameters (see XTR.TARGET...) determine which cell will have the focus on re-entry. But if the specified cell is not editable, then XTREE will revert to selection mode (i.e. the focus will be on an item or row, with the idea of being able to select it, rather than on a cell for the purposes of editing it.) The user can typically proceed from selection mode into editing mode by clicking on the desired cell or by using navigation keys. |
| • | In most cases, the preferred opcode (XTR.OPCODE) is XTROP_RESELECT. The eliminates the re-loading of the data source array into the tree. All editable cells, however, will be updated. So it is possible to update any cells, not just the one that was just edited or that will get the focus. |
| • | To further reduce visual thrashing, set the XTF_NOREDRAW bit in the XTREE Flags parameter. This doesn't stop the editable cells from being updated, but does skip all of the positioning and sizing optimization logic that determine how the tree initially appears (particularly the column widths). |
| • | If data outside of the set of editable cells needs to change (rows added, etc.), then you'll need to revert to opcode XTROP_REPLACE. In this case, the XTF_NOREDRAW flag has a slightly different effect: it doesn't stifle any display optimization logic, but it does eliminate the otherwise automatic deletion of the existing data before the new data is added. The main advantage of this is a slight reduction in the visual "flash." |
