XTREE/XTEXT Tab Performance

Added November 2010

This section discusses a performance refinement for Tab controls containing XTREE and XTEXT controls. It is primarily an ATE refinement, but could also apply to local Windows environments where you have large XTREE or XTEXT controls within TABs.

The idea is to avoid deleting and recreating the XTREE or XTEXT control when switching from one Tab pane to another, by just hiding the XTREE/XTEXT control and later reactivating it rather than recreating it.

Normally, the procedure for switching between TABs is to use CTLOP_CLR with the TAB's control ID to clear all of the controls on the pane before switching to the new pane and recreating all the controls for that pane. Destroying and recreating controls is usually just as fast as hiding/restoring them. But in the case of very large and complex controls, like XTREE and XTEXT, and especially in the ATE environment (where a lot of data must be sent from the server to the client to create and load the control), it would be more efficient to just make those controls disappear when switching to another pane, and then make them reappear when switching back to the pane containing them.

To accomplish that, you may now specify the code "!XT" (meant to suggest no XTREE or XTEXT) in the Txt parameter of the CTLOP_CLR call, e.g.:

xcall AUI, AUI_CONTROL, CTLOP_CLR, TABID, "!XT"

This causes any XTREE or XTEXT controls on the current Tab pane to be merely hidden instead of deleted.

Later, when you switch back to the pane containing the XTREE or XTEXT control(s), you just need to use CTLOP_CHG with the MBST_ENABLE and MBST_SHOW cstate flags to redisplay the control, rather than recreating it.

As a practical matter, to do this robustly, you will need the ctlid of the XTREE and/or XTEXT controls, which you would have from the XTR.CTLID and/or TXC.CTLID variables of the respecting routines. This assumes you are saving the xtrctl and/or txtctl parameter blocks for each XTREE/XTEXT control separately. If the ctlid parameter is non-zero, that implies that you must have previously created the control, and thus you may be able to just redisplay it with CTLOP_CHG. The returned cstatus value from the CTLOP_CHG operation will be >=0 if it succeeds, else it failed and you'll need to recreate the control. For example:

if XTR.CTLID > 0 then

    xcall AUI, AUI_CONTROL, CTLOP_CHG, XTR.CTLID, NUL_CTEXT$, MBST_ENABLE+MBST_SHOW, NUL_CMD$, NUL_FUNC$, CSTATUS

else

    CSTATUS = -1

endif

if CSTATUS < 0 then   ! we failed to redisplay the XTREE so recreate it

    ...

endif

 

Note: this is a client-side enhancement. (If an app tries to use the feature in an older client that doesn't support it, the CSTATUS parameter will indicate an error and you'll be able to recreate the control as before.)

History

2010 November, 5.1.1196:  Added to A-Shell