jimaultwins at yahoo.com
Fri Sep 2 03:11:16 CDT 2011
I think the key is 'focused object',
which can change based on user interaction and code execution.
A front script could test for the focused object, after trapping the
correct key stroke, then taking the desired action.
This could also be modified by a user preference or check box, as some
of the older programs did (such as word processor)
Caution: this is not my area of expertise, so test thoroughly before
confusing your users thoroughly :-)
On Sep 2, 2011, at 12:57 AM, FlexibleLearning wrote:
> 'Default' determines the button's visual appearance, and on some
> the change in border will grow the button dimensions a bit.
> It's behavior should be up to the designer, by Enter and/or Return key
> stroke, EnterInField and/or ReturnInField key stroke, or indeed none.
> I have never relied on the engine to trap the default button
> because it only works when nothing else is focussed.
> Hugh Senior
> Perte wrote:
> Thanks everyone.
> Jacque, Like you I'm currently using a returnKey handler for the
> card that
> sends mouseUp to the button to get round this.
> Craig, If I "put the defaultbutton of this card", I get the correct
> Also, I'm not seeing anything in the dictionary about the button
> size - is that in the defaultButton entry?
> Mark, maybe the difference between what you did and what I have is
> that I
> have 3 field controls on the card in addition to the default
> Button. Each
> of the field controls has lockText set to true and traversalOn set
> to false.
> Thing is, the dictionary says the default button behavior only works
> there is no active control on the card, but it doesn't define what
> an active
> control is so I don't know if the way I defined the field controls
> them as being inactive or not.
> I'm getting the behavior I want by using the card level returnKey
> but wondering whether I should enter a bug report about this. There
> seem any point in defining a button as the default button unless it
> acts as
> defined in the dictionary, but it would be good to know what
> qualifies as an
> "active control" before reporting it as a bug.
More information about the use-livecode