Steve: This is fine as long as you have no exit eeps on any of the other fields on the form. If any of the fields have exit eeps, then you risk them not firing if you click on a speed button. They might not have eeps now, but I can never guarantee that they won't in the future. So why not use a bit button to be on the safe side? What I'm looking for is some functionality where it is desirable to have the focus stay on the previous field rather than switch focus to the button. If there's a good reason to do that, then I'd like to know so that I can see if I could use that functionality too!
I used to use speed buttons all the time because I liked the fact that the user couldn't accidentally land on them and fire it off using a keyboard, but when I realized that exit eeps don't fire I decided to change them all over. Karen > My understanding is that these could be used in any situation where it is > necessary to invoke some set of functionality in an on-demand/ad-hoc > basis, such as when using some sort of VARIABLE FORM to browse a set of data, > then click a button to invoke a form for editing data associated with a > selected record. > > I use them like this regularly. > > I have also used them in what is still an "X-project" to > Start/Stop/Record_Finisher/Etc in a VARIABLE FORM that displays a "stopwatch" > and can log > finish times and positions in a race. > > I might be wrong about this one, but I seem to recall that some of these > form controls that are outside the TAB ORDER were "stripped of their > membership" therein as the result of one or more of us making a specific > request > to RBTI to have - actually, not have - this attribute. > > > > Just sharing my $0.02 on this, > > Steve in Memphis > > >
