Jacque to the rescue as ever! Thanks, you have nailed it. It's not just annoying, it's a bug - since an error or omission in the documentation is a bug too, as far as I am concerned: I have not seen a description of this very odd behaviour in the Dictionary or elsewhere (of course I could have missed it).
I came across this because of another annoying thing. My user is allowed to write stuff into a succession of fields, and then click on a button to get something done. The 'something' depends on whether any of the fields have been modified or not. It is quite possible for him (her) not to close the last revised field, but simply to go straight to clicking the button. This means that I can't rely on a 'closeField' message being generated even when a field is modified! Because of this anomaly I tried to detect field revision by looking at 'openField' messages instead, and just got into another fine mess. Maybe a correctly placed 'focus on nothing' will do it (should close the field where the cursor was last showing) - I will look into it. Still, it is extraordinary how many unintended consequences can arise from a tiny bit of code! Thanks again - it is good to know someone who knows. Graham On 23 Aug 2014, at 21:31, J. Landman Gay <jac...@hyperactivesw.com> wrote: > On 8/23/2014, 12:14 PM, Graham Samuel wrote: >> I have a palette with a lot of objects on it. There are some fields >> and some buttons. I have just realised that when I click on one of >> the buttons, before executing the 'mouseUp' handler for the button, >> the engine fires an 'openField' for one of the fields. I can't see >> what I have done to cause this, but it's causing chaos! Happens in >> the IDE and the corresponding standalone. > > You may have hit the common problem where the engine selects the text of the > first field that has traversalOn set to true when the stack gains focus. It's > annoying as hell. The fix is to turn off traversalOn and then after > opening/resuming, turn it back on again. If you do that, you have to turn it > off for all editable fields, because the engine will just select the next one > instead if you don't. > > Easier would be to try a resumeStack handler that calls another handler to > "focus on nothing" in half a second or so, after the engine is done > interfering. > > I wish there was a way to turn off this default behavior because there are as > many times you don't want it as when you do. Windows/Linux users can get > around it pretty easily by making sure a button is the lowest layered object > on the card; on those systems, buttons can be traversed and it isn't a big > deal if the button has an outline. That doesn't work on Macs, where buttons > don't use that property and the engine skips right to a field. > > And just to cover all bases, another really ugly way around it is to make an > editable field at layer 1 and place it offscreen where you can't see that > it's selected. That can interfere with the tabbing order though, because the > user can't see where the cursor went when it gets to that field. I usually do > the "focus on nothing" business, but if you do use an offscreen field you > don't need to change any scripts. > > -- > 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
