>So, in Bill's case, we seem to be missing the equivalent of a MouseUp for >keystrokes. Bill *can* get control when the mouse is used, so should he not >also be able to get control when the keyboard is used? > >Perhaps what is needed is another event applicable to BOTH, like a >"StateChange" event, so that one common code set could be used instead of >having to have two sets. > >There are no doubt other instances where there is currently a "missing" >keyboarding function. > >Keyboards are here for a while yet - try to convince a data-entry "pro" to >use the mouse. Acknowledging that, I suggest we need such functionality. This should be very high in the FoxWish list. VFP apps should be capable of heavy data grinding - it usually means being capable of quick data entry, which usually means both hands on, and no time for reaching the mouse every fifteen seconds. Any obstacle in the data entry interface should have higher priority than, say, wizard or builder bugs (in the KB I've noticed the opposite trend in previous versions - nearly 40% of entries used to cover gen*.prg and CatMan issues, or at least it seemed so). I'm writing this in Netscape Navigator mailer, and I'm quite angry that it doesn't have accelerator keys for "message up" or "message down" except arrows when I'm in the list frame. But then, I can't scroll the message from within that frame, unless I tab to the next frame, but then I can't tab back... so I have to click around. I can imagine what would data-entry pros like to say to us if we made such a lousy interface. If nothing else, there should be a definable key for a control's base class which would fire the .click event, which could default to space in case of a list control, so keypress of Space would trigger the .click and thus emulate (in absence of a better solution).