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 <4d_o...@pghrepository.org> 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 >>> <4d_tech@lists.4d.com> 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 < >>> 4d_tech@lists.4d.com> 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:4d_tech-unsubscr...@lists.4d.com >>> ********************************************************************** >> >> ********************************************************************** >> 4D Internet Users Group (4D iNUG) >> Archive: http://lists.4d.com/archives.html >> Options: https://lists.4d.com/mailman/options/4d_tech >> Unsub: mailto:4d_tech-unsubscr...@lists.4d.com >> ********************************************************************** > 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:4d_tech-unsubscr...@lists.4d.com **********************************************************************
