Typo in the previous message - not 120 ticks 20 or 30 :)
On Tue, 3 Dec 2019 15:21:39 +0000, Peter Jakobsson wrote: > Hi Chip > > Thanks for the reply. I’ve seen that approach on some web based systems. > > Could be good, could be bad. I see some users loving it and others > hating it. The machine trying to “second guess” that the user has > typed enough into the filter field sometimes makes it feel flaky > because it’s not immediately apparent what invoked the sudden query > unless you happen to know about the “timed action". At least with “ > type-ahead” the user knows that the keystroke will invoke a filter > at every character. > > Having said that, I watched a user show me their product lookup on a > manufacturer’s booking site the other day - it had a timer just like > the one you described. He really liked it. But he also wanted the > filter to be invoked with the return key. > > Regards > > Peter > > >> On 3 Dec 2019, at 15:12, Chip Scheide <[email protected]> wrote: >> >> have you considered using a timer to auto search for the user? >> >> i.e. user types: "App" >> and after a brief delay the searches auto executed using the user >> entered information? I use 120 ticks. >> >> then they do not have to hit return at all >> >> >> On Tue, 3 Dec 2019 00:26:24 +0000, Peter Jakobsson via 4D_Tech wrote: >>> Many thanks Kirk, and to those who responded to this thread. >>> >>> I’ve tried a variety of approaches in a virgin structure. The >>> simplest appears to be one that was first suggested by Jeremy Rusak >>> but others also alluded to: simply remove the “Focusable” property >>> from the default button (or a button with the Return key shortcut >>> attached). >>> >>> That allows the “Focus Object” functions to return the last object >>> instead of the current one. Hurrah !! >>> >>> By the way, the reason this is coming up is because users tend to >>> regard the “Search” widget as a form in its own right. So they >>> expect to be able to hit the return key to execute a query, then use >>> tab to move between form object in the host form (which contains both >>> the list and the search widget), then use the return key again to >>> accept the form…..IF the cursor is not in the search widget, in >>> which case they expect “return” to execute the query again and not >>> accept the form. >>> >>> Regards >>> >>> Peter >>> >>> >>> >>>> On 2 Dec 2019, at 15:58, Kirk Brooks via 4D_Tech >>>> <[email protected]> wrote: >>>> >>>> Hey Peter, >>>> I was just reading through your question and the answers and I >>>> noticed the >>>> solutions get sort of complicated. I think the reason is the task you're >>>> describing a little unusual. Having one keystroke, the return key, >>>> perform >>>> two very different actions can result in a non-intuitive UI. >>>> Consider, on a >>>> web page hitting the return key NEVER closes the page. In fact it open a >>>> new one. >>>> >>>> I've inadvertently set up this sort of thing on forms of my own and it's >>>> really annoying. When I want to use the Return or Enter key for anything >>>> besides accepting the form (eg. initiating a query, moving around on a >>>> listbox, etc. ) I put an invisible button on the form to trap the >>>> keystroke >>>> and then post an event, typically a TAB. This way I can still trap in the >>>> current object. For adding a CR to a text field I enable the After >>>> keystroke form event and trap the keystroke there. >>>> >>>> With this setup you will still handle the query stuff in the >>>> context of the >>>> relevant object. I think someone else mentioned using the loosing focus >>>> form event. That's good because some users will probably get used >>>> to using >>>> the TAB key to move around. There's nothing to stop your code from >>>> reselecting the search input object when it looses focus. The user won't >>>> know the difference. But if you do that how does the user get out of the >>>> field? >>>> >>>> For closing forms, not alerts, confirms or requests, with a given key I >>>> like to decide on some consistent action and stick to it on every >>>> form. You >>>> could use Shift key + Enter. Whatever you choose matters less, I think, >>>> than applying it consistently throughout the database. >>>> >>>> On Fri, Nov 29, 2019 at 1:44 PM Peter Jakobsson via 4D_Tech < >>>> [email protected]> wrote: >>>> >>>>> This is so that users can hit the return key to execute a query (like >>>>> Google style). But if the cursor is not in the filter field but >>>>> highlighting a row in the list then the return key should accept >>>>> the form >>>>> (via regular default button action). >>>>> >>>> >>>> -- >>>> Kirk Brooks >>>> San Francisco, CA >>>> ======================= >>>> >>>> What can be said, can be said clearly, >>>> and what you can’t say, you should shut up about >>>> >>>> *Wittgenstein and the Computer * >>>> ********************************************************************** >>>> 4D Internet Users Group (4D iNUG) >>>> Archive: http://lists.4d.com/archives.html >>>> Options: https://lists.4d.com/mailman/options/4d_tech >>>> Unsub: mailto:[email protected] >>>> ********************************************************************** >>> >>> ********************************************************************** >>> 4D Internet Users Group (4D iNUG) >>> Archive: http://lists.4d.com/archives.html >>> Options: https://lists.4d.com/mailman/options/4d_tech >>> Unsub: mailto:[email protected] >>> ********************************************************************** >> We have done so much, with so little, for so long; >> We are now qualified to anything with nothing <sigh> >> - unknown > > We have done so much, with so little, for so long; We are now qualified to anything with nothing <sigh> - unknown ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
