Updated March 2011

The XTROP_REPLACE operation allows you to replace the contents of an existing tree, without actually deleting the tree and recreating it. This is similar to XTROP_CREATE, except that it is optimized for the case where the new tree contents are similar to the old (same layout with minor additions/deletions/changes, as opposed to a complete new tree configuration). If the changes are particularly minimal, you can specify the XTF_NOREDRAW flag to minimize the visual "flash" that otherwise may occur when the various visual attributes are recreated and re-optimized.

ATE Notes

When using opcode XTROP_REPLACE in array mode, the server side of XTREE compares the new data Array with the old and applies two optimizations designed to minimize the amount of data sent between the server and ATE client. If the data is completely unchanged, it switches to XTROP_RESELECT, which eliminates the need to transmit or re-load the new data array entirely. Otherwise, if only a few rows have changed, then only those rows are transmitted and re-loaded. These optimizations are mostly useful in situations where cell-to-cell movement causes an exit and reentry, and you are obligated to use XTROP_REPLACE rather than XTROP_RESELECT because you have to make minor changes (such as updating a few other cells in response to a cell editing change), or you can't be sure if the data actually changed because you have to recreate the data from primary sources. A multi-user appointment scheduler would be an example of the latter, where you have to reload the schedule data from the database because you don't know if another user made a change in the meantime.

These optimizations have evolved over the period from edits 1150 to 1200, the server and client coordinate with each other to use only the optimizations that both understand, but work best when both sides are at the newest level.