EVENTWAIT improvement #1: AUI_EVENTWAIT now does a better job of identifying the current control ID when the EVENTWAIT was terminated by a keyboard or mouse event that EVENTWAIT was "entirely" in control of. For example, if you were in an EVENTWAIT for a dialog with a handful of buttons which generated the equivalent of F1, F2, F3, etc., and you exited by hitting F1 instead of tabbing around until you had the focus on the corresponding button and hitting ENTER, it will now try to match the exitcode generated by the button to the corresponding control. Similarly, if you click on a control to force an exit via the control's click string, it will now properly identify the control. (This is a relatively minor improvement, since in nearly all cases, it is the exitcode that you care about, not the control id, but it becomes more relevant when you re-enter the Eventwait operation, since in that case, the starting control ID could affect subsequent navigation logic.)
EVENTWAIT improvement #2: Most situations that previously caused EVENTWAIT to abort with exitcode 99 now instead act as if you had set the control ID parameter to 0 (i.e. defaulting to the focus on the first control). Such situations include: a) the control ID you specify doesn't exist or isn't a child of the specified parent ID; b) the exitcode you specify (in the case of EVW_EXCDFOCUS) doesn't match any control in the range. Although these are "errors" in the sense that you are asking EVENTWAIT to do something that is impossible, they are so minor that reporting them as errors and forcing your application to deal with them is more hassle than it is worth. Under the new scheme, if you have the GUI TRACE option on, it will log the error, but otherwise will just ignore it and revert to putting the focus on the first control in the range specified by the parent.