This field may be used to specify the ID of a control that should be deleted just before XTREE updates its display and starts waiting for user input. This is handy for deleting "in progress" displays (see Animated Graphics) that you create prior to calling a large or complicated XTREE that may take more than a couple of seconds to load. See the sample program XTRA7 for an example of this.
Note that XTEXT has an analogous field (TXC.DELCTLID) in its txtctl parameter. Most of the comments in this topic relating to XTR.DELCTLID and XTREE apply equally well to TXC.DELCTLID and XTEXT, except the xtr.miscflags linkage with the standard and custom progress bars.
This field is declared as B,4 rather than the usual B,2 used for storing control IDs to allow for the possibility that the control you want to delete when XTREE becomes active, was actually created externally. In that case, it would not have an A-Shell control ID, but it would have a standard window handle, which you can place in this field instead of the control ID. See MX_FINDWINDOW for one possible method of determining the window handle of an externally-created control.
Automatic Updating of Progress Bar During Load
In the case of ATE, the contents of the tree must be sent from the server to the client, which could potentially take several seconds, depending on the amount of data and the speed of the connection. To keep the user informed of the load progress, XTREE supports an internal mechanism to update your progress bar as the data is transferred. See the XTMF_STDPRGBAR and XTMF_CUSPRGBAR flags in XTR.MISCFLAGS for details.
Notes and Warnings
If the XTREE control has no explicit parent (i.e. its parent is the main window), then if you create a modal dialog to contain your <processing> or <in progress> display, the XTREE will by default become a child of that dialog. This will not work, because when XTREE deletes the dialog, it will end up deleting itself. Fortunately, there are multiple workarounds:
| • | Make your <processing> dialog be modeless by adding the MBF_MODELESS bit to its ctype. Since modeless dialogs do not automatically become the parent of controls with no explicit parent of their own, the XTREE will remain independent. |
| • | Do not use a dialog for your <processing> display. Instead, just use an ordinary control without a parent, just like XTREE is, so that they become siblings. (You can even put it right where the XTREE would normally display.) |
| • | Put the XTREE in a dialog of its own. |
When XTR.DELCTLID is specified and XTR.PARENTID is zero, you must take care that there are no controls (aside from the XTR.DELCTLID control) that would be overlapped by the XTREE screen area. Normally, in this situation, XTREE will save, hide, and later restore any such controls. But doing this would cause the <processing> control to be restored on exit from XTREE (if it was overlapping).
