Sorry to enter the thread late, but tried to implement similar functionality several years ago. Ended up with variable set in On getting / on loosing focus. Button that handled Enter checked value of the variable and either processed script or saved record.
Final implementation was more complex, it had event handler method that stored last pressed key and everything was handled in On loosing focus event, executing different code for leaving with enter, tab or mouse click. But doing it again, I would go for something simpler. Peter Bozek On Tue, Dec 3, 2019 at 4:21 PM Peter Jakobsson via 4D_Tech < 4d_tech@lists.4d.com> 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 <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 > ********************************************************************** -- -- Peter Bozek ********************************************************************** 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 **********************************************************************
