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 **********************************************************************
