actually, with this code (default removed)
showevents_jqtide_ 1
wd 'reset'
wd 'pc a closeok escclose'
wd 'cc one button'
wd 'cc two button'
wd 'cc three button'
wd 'pshow'
pressing enter does nothing. space still executes the first button, and tab
will change which button responds to space.
though I did find a solution in this code:
showevents_jqtide_ 1
wd 'reset'
wd 'pc a closeok escclose'
wd 'cc t edit'
wd 'cc tm editm' wd 'cc one button'
wd 'cc two button'
wd 'cc three button'
wd 'pshow'
a_t_button (did not know it existed) gets fired when enter is pressed in the
edit control, and no event is fired when enter is pressed in editm (though most
other chars are... minor issue not worth worrying about), so a straightforward
solution to proper default button behaviour is to define edit_button handlers
to forward their event to "ok_button". This even provides the most flexible
possible choices with one good idea being to validate just that field even if
OK/save validates all fields.
----- Original Message -----
From: chris burke <cbu...@jsoftware.com>
To: General forum <gene...@jsoftware.com>
Cc:
Sent: Friday, May 29, 2015 12:23 PM
Subject: Re: [Jgeneral] wd button default
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 <gene...@jsoftware.com>
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 <cbu...@jsoftware.com>
> To: General forum <gene...@jsoftware.com>
> 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 <
> gene...@jsoftware.com>
> 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 <bbill....@gmail.com>
> > To: General forum <gene...@jsoftware.com>
> > 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
> > <gene...@jsoftware.com> 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 <bbill....@gmail.com>
> > > To: General forum <gene...@jsoftware.com>
> > > 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" <
> > > gene...@jsoftware.com> 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 <cbu...@jsoftware.com>
> > >> To: General forum <gene...@jsoftware.com>
> > >> 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 <
> > >> gene...@jsoftware.com>
> > >> 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
----------------------------------------------------------------------
For information about J forums see http://www.jsoftware.com/forums.htm
