I love this list for the education I get as much as for the practical advice.
After hearing everything that has been said in this thread (mostly by Jacque, but also by others), here is the solution that works. To recap briefly, the problem is what Jacque calls "the engine's long-standing behavior that automatically focuses on the first object that has traversalOn set to true whenever the card changes." In my case, I wanted a field called "SearchTarget" to receive the focus after the user clicks the Find button, so the user could type another target for the search. I tried using [focus on field "SearchTarget"] at the end of the mouseUp script of the Find button, and it did not work: the focus always ended up on the card. Here is what does work: ==== This handler is in the field's script: on focusOnMe select after char -1 of me end focusOnMe This is the last line in the script of the Find button: send "focusOnMe" to field "SearchTarget" in 100 milliseconds ==== Thanks, everybody! Slava > -----Original Message----- > From: use-livecode-boun...@lists.runrev.com [mailto:use-livecode- > boun...@lists.runrev.com] On Behalf Of J. Landman Gay > Sent: Wednesday, July 06, 2011 12:52 PM > To: How to use LiveCode > Subject: Re: autoHilite and focus (following Jacque's solution) > > On 7/6/11 2:06 AM, Slava Paperno wrote: > > But then I added other buttons to the same card, and found that if any > > of them has AutoHilite set to true, my focus command is undone, and > > the focus moves to the card itself as soon as the mouseUp handler is > > done in the Find button. I do want the user to see the visual feedback > > from those buttons, and I don't want their Focus with Keyboard property set to > true. > > I think what you're seeing is the engine's long-standing behavior that > automatically focuses on the first object that has traversalOn set to true > whenever the card changes. On Windows/Linux, it can be a button. On OS X, > where buttons by default don't respond the same way, it's a field. > This has been known to drive developers gibbering into the streets, and I wish > there were a way to turn that off. > > But since we're stuck with it, one solution is to make your Find field the first one > (the lowest layer) if possible. Or, see my suggestion in my other post. Or add an > (ugly) command to an openCard handler that sends a message in 1 millisecond > to another handler, which in turn focuses on nothing (or on your field if you > prefer.) > > > > > With the focus gone, my user will probably try to press Tab to return > > the focus to the input field. But when the focus is on the card, none > > of my buttons receives that Tab keypress. > > Put the tabkey handler into the stack or card and check "the target" to see which > object received the message. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode