As mentioned, it makes no difference whether the button is set to default or to autodefault. Also, the same behaviour is seen in plain Qt.
In an ordinary (non-dialog) form, when setting a single control, default and autodefault should mean the same thing. On 29 May 2015 at 09:14, 'Pascal Jasmin' via General <[email protected]> wrote: > The reason the your example works is that default is actually setting > autodefault, which just affects whether a button will respond to enter when > it has focus. Your form sets the first button as focused on show. If you > press tab, then space, other button events can be fired, but they do not > respond to enter. > > autodefault is an extremely minor convenience at best, and probably a bad > programming idea. (The user actually prefers that enter always triggers > the OK/Save record action, and tab tab ... space is much faster one handed > data entry) > > > > > ----- Original Message ----- > From: chris burke <[email protected]> > To: General forum <[email protected]> > Cc: > Sent: Friday, May 29, 2015 12:03 PM > Subject: Re: [Jgeneral] wd button default > > Qt's treatment of button default is a mystery to me. > > If the first button is set to default, then pressing Enter will trigger a > JQt button event. Try: > > showevents_jqtide_ 1 > wd 'reset' > wd 'pc a closeok escclose' > wd 'cc one button default' > wd 'cc two button' > wd 'cc three button' > wd 'pshow' > > If any other button is set to default, then just pressing Enter after the > form is displayed will not trigger a Jqt button event. However, if you > first click the button, then pressing Enter afterwards triggers the button > event. > > This behaviour can be reproduced in Qt, outside of JQt, i.e. just create > the buttons and set one as default: > > ... > QPushButton *b0=new QPushButton("B0"); > QPushButton *b1=new QPushButton("B1"); > QPushButton *b2=new QPushButton("B2"); > b0->setDefault(true); > ... > > So JQt is just reproducing the standard Qt behaviour. Perhaps we are just > missing something that needs to be done first. > > > 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. > > The same behaviour is seen whether we set Default or AutoDefault. For a > normal form (non-dialog), AutoDefault is off by default, so this is not an > issue. > > > 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. > > In JQt if a button gets a click event on pressing Enter, then the Form does > not get an Enter event. > > > On 29 May 2015 at 08:54, 'Pascal Jasmin' via General < > [email protected]> > wrote: > > > 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 > > > ---------------------------------------------------------------------- > 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
