Another great film by Jorge. And a nice reminder of great line from A-Shell Conferences past - the acknowledgment by Kevin that, as a compromise in order to obtain an automatic GUI transformation of his apps, he would be "willing to recompile". We may not have quite achieved even that compromised goal, but he will be happy to know that his vision is still guiding us.
As for the "AUTO-COMBO", the concept seems pretty straightforward. I'm not sure why I didn't recognize earlier that exitcode 29 (request for
self-service combo display display) and exitcode 30 (request for auto-complete display) could probably be merged. As you correctly recognized, the two kinds of exits are effectively the same for practical purposes. The main difference lies in the format of the setdef that your app returns to INFLD with (i.e. a traditional combo list, or the more sophisticated xtree coldef+list). But this is a choice the application can decide for itself based on its own logic, without needing the exitcode distinction to guide it.
To clarify, once the exitcode 29 is triggered, existing applications will respond in one of two ways:
a) open up a separate window, perhaps using XTREE, or perhaps a full dialog, to allow the user to generate a list and select from it.
b) replace the "..." in setdef with a standard list of choices and return to the original field, which would now act as a regular combo box. In this case, since it is no longer a self-combo, there would be no "auto-combo" either.
From the standpoint of existing application internal logic, it wouldn't break anything if the self-combo were to turn into an "auto-combo", since the only difference would be that the exitcode 29 could be generated by another event (changing the field and then waiting 1/2 second), in addition to the previous methods of clicking the down arrow button or hitting the down arrow key.
But from the user's standpoint, this new method of triggering the exitcode 29 might be a significant annoyance, if they were accustomed to typing a field value and hitting ENTER (rather than always hitting the down arrow). Unless the user was a fast and skilled typist, it is likely that the auto-complete event timer would trigger the exitcode 29 before the complete field was entered. Worse, if they weren't watching the screen, they wouldn't realize that the field exited and a new window or combo list appeared, and they might then get some unexpected result by typing a few more characters and hitting ENTER.
(If your program used the
) TYPE code to re-enter the new field with the partial contents of the original field and the cursor at the end of it, then maybe it would work out that even if the user didn't realize what was happening, the end result would be nearly the same, but that's a big
if.)
So, the question is, do you really think that automatically converting existing self-combos to "auto-combos" would be more of a benefit than an annoyance to existing users?
I guess I could imagine this being a user-level configuration choice, in which case it wouldn't really belong in the MIAME.INI (OPTIONS=AUTOCOMBO) but in the Misc. Settings or to be set by the application using a MIAMEX function.
On the other hand, a possible compromise would be to change the timer value for the "auto-combo" from 1/2 second (after any field change) to something longer, perhaps 2 seconds, effectively minimize the likelihood of the kind of user confusion I just described.
(*)
