AutuDefault = true causes a button that has the focus (space key will execute 
it) to also respond to enter key, even if there is a default button defined.  
It is a very minor interface feature that few people use, and arguably a bad 
idea (If I want to tab to a button to execute it with a key, the space bar is 
much bigger and easier to hit, its a standard with all applications, and if I 
hit enter, I can still access the main ("OK") application function.

Default = true is very much like form_enter.  The enter key forwards a call to 
the button handler.

The problems you mention with form_enter seem fairly minor.  There are 2 
general interface standards for dealing with the enter key on a form that has 
say a multiedit control or table cell or other control that responds to enter:

1. Force user to hit ctrl-Enter to send Enter key to control (if there is a 
form_enter handler.  Otherwise Enter key works as in jqt now).  This solves the 
issue that probably exists in that the form gets keystrokes first, and there is 
no easy way to "rebroadcast" a key stroke if it should be captured by a 
control.  In terms of the wd system, this could be relatively straightforward 
as "if form_enter defined, then only capture enter and not ctrl-enter".  This 
is not terrible UI, even if not completely standard.  Very easy for form 
developer to handle (just forward to OK, or don't have a form_enter 
definition.)  The don't have a form_enter handler is the best idea for say an 
email composition form:  Even if the enter key could be unambiguously used to 
trigger the Send action in the to and subject fields, just don't have a 
form_enter handler is the best advice.

2. Manually check in form_enter if special controls have focus and then either 
choose to call the OK button or other response to Enter, or insert a linefeed 
at the select point of that control.   This may be the most standard UI, but 
its also generally a bad idea for most user expectations of enter key on your 
form:  They for sure want enter to add a newline in the message body;  They 
don't want enter to sometimes trigger "Send/OK" because that action almost 
always creates irreversable world wide side effects.  Often your OK (or Send) 
button has a form-wide shortcut, but the user expects that enter will create 
newlines... even in the To: field, the user might hope that the enter key makes 
the field taller so as to enter more names (but that is easily supported by an 
initially short To: multiline field).  Basically, the user does not know if an 
edit field is multiline or not, just because it is initially 1 row high.

So alternative 1 seems like it could be easiest, and happens to cover all 
useful programming applications where form_enter is a desired feature.  
ctrl-enter interface is useful for data entry forms, where entering linefeeds 
is a rare action in "comments/Notes" fields, but record save is a common action 
that needs easy access after changing any field.

If the solution is difficult, consider:

wd 'mb input text "enter password" "password: " '

which does work as wd 'cc OK button default;' should on a form.  

Perhaps a useful alternative would be if this syntax (or equivalent 
alternative) did not give an error

wd 'mb input text password "enter password" "password: " '

basically users expect the enter key on a password form will submit it, but 
also expects that the text stays dotted/hidden.  Perhaps also the point that 
there is no wdq trace of the plaintext password has application security 
benefits, and the data can be made never accessible outside of a local function 
storage also has security benefits.

The ideal implementation of 'button default' would be:

Not use the qt behaviour.  Instead auto create form_enter verb that calls 
button_name_handler, and does not get triggered by ctrl/alt/shit enter.  But 
this ideal is followed very closely with just allow manual form_enter, and 
remove the default property for buttons presuming that no one has found a 
useful effect for it in jqt.

Currently controls don't respond to ctrl-enter.  Ideally they would, to cover 
the data entry scenario (most common worldwide form programming), but 
ctrl-enter does show up in sysdata (I believe) so it is possible for form 
programmer to handle it outside of form_enter.


----- Original Message -----
From: bill lam <[email protected]>
To: General forum <[email protected]>
Cc: 
Sent: Friday, May 29, 2015 3:44 AM
Subject: Re: [Jgeneral] wd button default

jqt will setAutoDefault(true) for the default button. but I am not
sure if setDefault(true) should be used instead (I'm too slow to
understand the documentation).  Also the parent form in jqt is not a
QDialog, instead it is a top level QWidget without any parent, so I
don't know if default button can apply.

IIRC the problem with form_enter in jqt is that it is always triggered
whenever an Enter key has been pressed, no matter the child control
had processed it or not.  If you examine the event log, you might
notice this.


On Fri, May 29, 2015 at 3:06 PM, 'Pascal Jasmin' via General
<[email protected]> wrote:
> http://stackoverflow.com/questions/11887938/how-to-make-a-qpushbutton-pressable-for-enter-key
>
> default in qt is supposed to make a button (intended behaviour) respond to 
> form_enter as well.  When I add that property though, it disables the code 
> behind the button (it in fact erases the button handler from the form), 
> though the wdq list looks the same. (the button no longer responds to mouse 
> clicks, and still doesn't react to enter key)
>
> Perhaps it is a relatively easy fix to avoid erasing the button handler.  I 
> can add it after the form is created, but I seem to have trouble getting the 
> locales right.
>
>
> ----- Original Message -----
> From: bill lam <[email protected]>
> To: General forum <[email protected]>
> Cc:
> Sent: Friday, May 29, 2015 12:57 AM
> Subject: Re: [Jgeneral] wd button default
>
> there was a form_enter event in j602 which should be what you want, but it
> is difficult to duplicate in j803.
>
> there may be some bug in default button or it is the behavior under Qt.  I
> am not sure because I have never used default button (j6 or j8).
>
> I would suggest not to depend on these features (form_enter or default
> button).
> On May 29, 2015 12:13 PM, "'Pascal Jasmin' via General" <
> [email protected]> wrote:
>
>> thanks Chris,
>>
>> I don't see anything useful happening as a result of adding a default
>> property to a button.
>>
>> I can see that defining a __default function does intercept keystrokes in
>> 'sysdata' but the enter key does not get "captured" (though backspace
>> does).  Strangely, pressing the enter key repeats the last key that was in
>> sysdata.
>>
>> Is there a recommended way to tell if the enter key has been pressed?
>>
>>
>>
>>
>> ----- Original Message -----
>> From: chris burke <[email protected]>
>> To: General forum <[email protected]>
>> Cc:
>> Sent: Thursday, May 28, 2015 9:51 PM
>> Subject: Re: [Jgeneral] wd button default
>>
>> Usually you want to handle wd events. Use showevents_jqtide_ to display the
>> events in the session. If displaying wdq, note that the first 3 rows show
>> the event handlers. These are searched in order and the first one found
>> will be executed.
>>
>> Escclose simply means that pressing Esc will signal a cancel event. If you
>> also set closeok on the parent, then pressing Esc will close the form
>> without an event, for example the image form in the Qt demos has this
>> property.
>>
>>
>> On 28 May 2015 at 14:52, 'Pascal Jasmin' via General <
>> [email protected]>
>> wrote:
>>
>> > I don't think that the 'button default' command works or works sensibly.
>> > In the jqt controls demo, neiter escape nor enter closes the form despite
>> > the cancel button having the default property set, and escclose is also
>> set
>> > on the form.
>> >
>> > From peeking at wdq, it appears as though I might need to create a verb
>> > called default for my form?
>> >
>> > How I expect it to work.... pressing enter while on a control that is not
>> > multiline edit, should execute the code already assigned to the button
>> > marked as default.  ideally, the escclose property should be attachable
>> to
>> > a button, and pressing escape runs the same code that clicking on the
>> > "cancel" button would do.
>> > ----------------------------------------------------------------------
>> > For information about J forums see http://www.jsoftware.com/forums.htm

>
>>
>> >
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>> ----------------------------------------------------------------------
>> For information about J forums see http://www.jsoftware.com/forums.htm
>>
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
> ----------------------------------------------------------------------
> For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm

Reply via email to