When the user clicks on an inactive XTREE, it creates potential complications for the application. Typically, the xtr'kbdstr parameter of the inactive xtree will be used to generate an exitcode indicating which control was clicked, and the control currently with the focus will exit with that exitcode. The application would then typically call XTREE for the clicked-on tree. The complications arise when the click event has (or should have) more consequences than simply putting the focus on that XTREE.
For example, if the target tree uses SelChgExit or ClickExit, the click event might logically need to trigger one or both of those exitcodes. In the case of a right-click, if there was a context menu defined, the user would expect it to appear (in addition to the tree getting the focus).
The act of clicking on the inactive tree might also have ramifications for the control that previously had the focus, perhaps INFLD or even another XTREE. For example, in either of those cases, exit validation may be needed, which could potentially put the application the position of having to ignore the original click on the inactive tree, in order to enforce some data entry rules in the previously active tree or field.
The general procedure for dealing with these complications is (and has been) as follows:
| • | The click on the inactive tree generates the exitcode associated with the xtr'kbdstr field for that tree. |
| • | The currently active control (presumably being handled by an XCALL) exits with that exitcode. |
| • | The application performs any exit validation or cleanup necessary for the field/control just exited. |
| • | Assuming no problems so far, it then calls XTREE (probably with XTROP_RESELECT) to activate the tree just clicked on. |
| • | Once activated, that tree should try to proceed with processing the secondary events associated with the click that occurred when the tree was inactive. For example, if it was a right-click on a column that had a PopupMenu, it should then display the context menu. Or if the click caused the selection to be moved to another row and SelChgExit was defined, then the tree should exit with the exitcode defined for the SelChgExit. If the inactive click was on a checkbox cell, the contents of the checkbox should now be toggled, and if validating, the tree should exit with exitcode -48. Etc. |
The refinement here is not so much a change of procedure but a review and slight cleanup to reaffirm that it actually works as just described. In addition, in the case where the inactive click could lead to multiple exitcodes, those would now be returned in the xinfo parameter (if specified).
Finally, there is one new feature associated with this "refinement": A new flag, XTF2_CLRDEFER (&h0100) may be passed to tell XTREE to ignore any previous inactive click and to clear any secondary events associated with it. This would be useful in the case where the operation interrupted by the click on the inactive XTREE wasn't properly completed, causing the application to effectively ignore the inactive XTREE click. But at some point later, the application may decide to call that XTREE for other reasons, and we wouldn't want to then have to deal with the deferred effects of the original click event. Currently, inactive click events are discarded after about 2 seconds, but that is not necessarily an appropriate time period. The new flag allows for somewhat more application control.
