[PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Ken Brown-6
---
 site.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/site.cc b/site.cc
index 641a6bb..64e56a8 100644
--- a/site.cc
+++ b/site.cc
@@ -759,7 +759,9 @@ bool SitePage::OnMessageCmd (int id, HWND hwndctl, UINT code)
     {
     case IDC_EDIT_USER_URL:
       {
- // FIXME: Make Enter here cause an ADD, not a NEXT.
+ // Set the default pushbutton to ADD if the user is entering text.
+ if (code == EN_CHANGE)
+  SendMessage (GetHWND (), DM_SETDEFID, (WPARAM) IDC_BUTTON_ADD_URL, 0);
  break;
       }
     case IDC_URL_LIST:
--
2.15.1

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Jon TURNEY
On 04/12/2017 15:58, Ken Brown wrote:

> ---
>   site.cc | 4 +++-
>   1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/site.cc b/site.cc
> index 641a6bb..64e56a8 100644
> --- a/site.cc
> +++ b/site.cc
> @@ -759,7 +759,9 @@ bool SitePage::OnMessageCmd (int id, HWND hwndctl, UINT code)
>       {
>       case IDC_EDIT_USER_URL:
>         {
> - // FIXME: Make Enter here cause an ADD, not a NEXT.
> + // Set the default pushbutton to ADD if the user is entering text.
> + if (code == EN_CHANGE)
> +  SendMessage (GetHWND (), DM_SETDEFID, (WPARAM) IDC_BUTTON_ADD_URL, 0);
>   break;
>         }
>       case IDC_URL_LIST:
>

Very nice.  That fixme has been there since 2002 (and the bug probably
longer...)

I thought perhaps we might need to reset the default control if the
focus is moved to another control after IDC_EDIT_USER_URL so that enter
works correctly then, but that doesn't seem to be the case.

Please apply.

The search textbox on the package chooser page needs the same fix.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Ken Brown-6
On 12/5/2017 7:58 AM, Jon Turney wrote:
> Please apply.

Done.

> The search textbox on the package chooser page needs the same fix.

It's not immediately clear to me how to do this, since I don't know what
the default pushbutton should be while the user is typing in the search box.

One possibility is to convert the label "Search" to the left of the box
to a SEARCH pushbutton, whose effect is to call OnTimerMessage().  If we
make this the default, then pressing Enter will cause the search filter
to immediately take effect, which is probably what the user expects.

Or do you have a better idea?

Ken
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Ken Brown-6
On 12/5/2017 11:03 AM, Ken Brown wrote:

> On 12/5/2017 7:58 AM, Jon Turney wrote:
>> Please apply.
>
> Done.
>
>> The search textbox on the package chooser page needs the same fix.
>
> It's not immediately clear to me how to do this, since I don't know what
> the default pushbutton should be while the user is typing in the search
> box.
>
> One possibility is to convert the label "Search" to the left of the box
> to a SEARCH pushbutton, whose effect is to call OnTimerMessage().  If we
> make this the default, then pressing Enter will cause the search filter
> to immediately take effect, which is probably what the user expects.
Something like the attached?  This might not be quite right, because the
previous default button is never restored.  I'm not sure how important
that is.

Ken


0001-Fix-response-to-Enter-in-the-chooser-textbox.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Jon TURNEY
On 05/12/2017 17:32, Ken Brown wrote:

> On 12/5/2017 11:03 AM, Ken Brown wrote:
>> On 12/5/2017 7:58 AM, Jon Turney wrote:
>>> The search textbox on the package chooser page needs the same fix.
>>
>> It's not immediately clear to me how to do this, since I don't know
>> what the default pushbutton should be while the user is typing in the
>> search box.
>>
>> One possibility is to convert the label "Search" to the left of the
>> box to a SEARCH pushbutton, whose effect is to call OnTimerMessage().  
>> If we make this the default, then pressing Enter will cause the search
>> filter to immediately take effect, which is probably what the user
>> expects.
It seems a bit weird to have a button which automatically pushes itself
half a second after you finish typing.

Attached is my attempt, which (ab)uses an invisible button.

> Something like the attached?  This might not be quite right, because the
> previous default button is never restored.  I'm not sure how important
> that is.

I think it's something that should be done, if possible, so I added that.

I'm a bit puzzled that IDD_SITE apparently doesn't need anything to do
that, but IDD_CHOOSE does...

0001-Fix-response-to-enter-in-the-chooser-search-textbox.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Ken Brown-6
On 12/7/2017 1:35 PM, Jon Turney wrote:

> On 05/12/2017 17:32, Ken Brown wrote:
>> On 12/5/2017 11:03 AM, Ken Brown wrote:
>>> On 12/5/2017 7:58 AM, Jon Turney wrote:
>>>> The search textbox on the package chooser page needs the same fix.
>>>
>>> It's not immediately clear to me how to do this, since I don't know
>>> what the default pushbutton should be while the user is typing in the
>>> search box.
>>>
>>> One possibility is to convert the label "Search" to the left of the
>>> box to a SEARCH pushbutton, whose effect is to call OnTimerMessage().
>>> If we make this the default, then pressing Enter will cause the
>>> search filter to immediately take effect, which is probably what the
>>> user expects.
>
> It seems a bit weird to have a button which automatically pushes itself
> half a second after you finish typing.
>
> Attached is my attempt, which (ab)uses an invisible button.

I agree, this is better than my version.

>> Something like the attached?  This might not be quite right, because
>> the previous default button is never restored.  I'm not sure how
>> important that is.
>
> I think it's something that should be done, if possible, so I added that.

In my testing, 'Next' does indeed become the default button after I
click outside of the textbox, but there's no visual indication of this.

The MSDN page for DM_SETDEFID
(https://msdn.microsoft.com/en-us/library/windows/desktop/ms645413(v=vs.85).aspx)
mentions a different situation where button highlighting doesn't
accurately reflect the default button.  In that case it suggests sending
a BM_SETSTYLE message to change the border style.

I looked at the documentation for BM_SETSTYLE, but it wasn't obvious to
me what do do.

Ken

Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Brian Inglis
On 2017-12-07 13:46, Ken Brown wrote:

> On 12/7/2017 1:35 PM, Jon Turney wrote:
>> On 05/12/2017 17:32, Ken Brown wrote:
>>> On 12/5/2017 11:03 AM, Ken Brown wrote:
>>>> On 12/5/2017 7:58 AM, Jon Turney wrote:
>>>>> The search textbox on the package chooser page needs the same fix.
>>>> It's not immediately clear to me how to do this, since I don't know what the
>>>> default pushbutton should be while the user is typing in the search box.
>>>> One possibility is to convert the label "Search" to the left of the box to a
>>>> SEARCH pushbutton, whose effect is to call OnTimerMessage(). If we make this
>>>> the default, then pressing Enter will cause the search filter to immediately
>>>> take effect, which is probably what the user expects.
>> It seems a bit weird to have a button which automatically pushes itself half a
>> second after you finish typing.
>> Attached is my attempt, which (ab)uses an invisible button.
> I agree, this is better than my version.
>>> Something like the attached?  This might not be quite right, because the
>>> previous default button is never restored.  I'm not sure how important that is.
>> I think it's something that should be done, if possible, so I added that.
> In my testing, 'Next' does indeed become the default button after I click
> outside of the textbox, but there's no visual indication of this.
> The MSDN page for DM_SETDEFID
> (https://msdn.microsoft.com/en-us/library/windows/desktop/ms645413(v=vs.85).aspx) mentions
> a different situation where button highlighting doesn't accurately reflect the
> default button.  In that case it suggests sending a BM_SETSTYLE message to
> change the border style.
> I looked at the documentation for BM_SETSTYLE, but it wasn't obvious to me what
> do do.

Seems like you want to change the button state not style - checking around you
might want to use Button_SetState macro or BM_SETSTATE message TRUE to
highlight, FALSE to reset:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb849168(v=vs.85).aspx

with Button_SetStyle macro or BM_SETSTYLE message style BS_DEFPUSHBUTTON |
BS_CENTER | BS_VCENTER | BS_TEXT | ...  as appropriate, so that ENTER works like
a click:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb775951(v=vs.85).aspx

When content is first added to the Search text box and while content exists, you
may want to BM_SETSTATE FALSE and clear BS_DEFPUSHBUTTON on [Next], then after
the next action, BM_SETSTATE TRUE and set BS_DEFPUSHBUTTON on [Next].

--
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Ken Brown-6
On 12/7/2017 11:55 PM, Brian Inglis wrote:

> On 2017-12-07 13:46, Ken Brown wrote:
>> On 12/7/2017 1:35 PM, Jon Turney wrote:
>>> On 05/12/2017 17:32, Ken Brown wrote:
>>>> On 12/5/2017 11:03 AM, Ken Brown wrote:
>>>>> On 12/5/2017 7:58 AM, Jon Turney wrote:
>>>>>> The search textbox on the package chooser page needs the same fix.
>>>>> It's not immediately clear to me how to do this, since I don't know what the
>>>>> default pushbutton should be while the user is typing in the search box.
>>>>> One possibility is to convert the label "Search" to the left of the box to a
>>>>> SEARCH pushbutton, whose effect is to call OnTimerMessage(). If we make this
>>>>> the default, then pressing Enter will cause the search filter to immediately
>>>>> take effect, which is probably what the user expects.
>>> It seems a bit weird to have a button which automatically pushes itself half a
>>> second after you finish typing.
>>> Attached is my attempt, which (ab)uses an invisible button.
>> I agree, this is better than my version.
>>>> Something like the attached?  This might not be quite right, because the
>>>> previous default button is never restored.  I'm not sure how important that is.
>>> I think it's something that should be done, if possible, so I added that.
>> In my testing, 'Next' does indeed become the default button after I click
>> outside of the textbox, but there's no visual indication of this.
>> The MSDN page for DM_SETDEFID
>> (https://msdn.microsoft.com/en-us/library/windows/desktop/ms645413(v=vs.85).aspx) mentions
>> a different situation where button highlighting doesn't accurately reflect the
>> default button.  In that case it suggests sending a BM_SETSTYLE message to
>> change the border style.
>> I looked at the documentation for BM_SETSTYLE, but it wasn't obvious to me what
>> do do.
>
> Seems like you want to change the button state not style - checking around you
> might want to use Button_SetState macro or BM_SETSTATE message TRUE to
> highlight, FALSE to reset:
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/bb849168(v=vs.85).aspx
>
> with Button_SetStyle macro or BM_SETSTYLE message style BS_DEFPUSHBUTTON |
> BS_CENTER | BS_VCENTER | BS_TEXT | ...  as appropriate, so that ENTER works like
> a click:
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/bb775951(v=vs.85).aspx

Thanks for the suggestions, but I tried various BM_SETSTATE and
BM_SETSTYLE messages, and I couldn't find anything that worked: 'Next'
remained unhighlighted.

Ken
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Jon TURNEY
In reply to this post by Ken Brown-6
On 07/12/2017 20:46, Ken Brown wrote:

> On 12/7/2017 1:35 PM, Jon Turney wrote:
>> On 05/12/2017 17:32, Ken Brown wrote:
>>> On 12/5/2017 11:03 AM, Ken Brown wrote:
>>>> On 12/5/2017 7:58 AM, Jon Turney wrote:
>>>>> The search textbox on the package chooser page needs the same fix.
>>>>
>>>> It's not immediately clear to me how to do this, since I don't know
>>>> what the default pushbutton should be while the user is typing in
>>>> the search box.
>>>>
>>>> One possibility is to convert the label "Search" to the left of the
>>>> box to a SEARCH pushbutton, whose effect is to call
>>>> OnTimerMessage(). If we make this the default, then pressing Enter
>>>> will cause the search filter to immediately take effect, which is
>>>> probably what the user expects.
>>
>> It seems a bit weird to have a button which automatically pushes
>> itself half a second after you finish typing.
>>
>> Attached is my attempt, which (ab)uses an invisible button.
>
> I agree, this is better than my version.
>
>>> Something like the attached?  This might not be quite right, because
>>> the previous default button is never restored.  I'm not sure how
>>> important that is.
>>
>> I think it's something that should be done, if possible, so I added that.
>
> In my testing, 'Next' does indeed become the default button after I
> click outside of the textbox, but there's no visual indication of this.
This is interesting: if you use TAB to move the focus out of the
textbox, then first "Clear" gets highlight (because it's a pushbutton
and enter pushes it), TAB again and "Current is selected (but "Next"
gets the highlight, because that's what enter pushes)

If you click to move the focus, it only seems to update the highlight
the second time you do that.

Which I guess suggests we should be ensuring the highlight is drawn on
EN_KILLFOCUS?

But once I do that, it seems I need to explicitly remove as well, which
gives the attached, incremental patch.

0001-Explicitly-remove-defpushbutton-style-from-Next-butt.patch (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Jon TURNEY
In reply to this post by Ken Brown-6
On 08/12/2017 14:47, Ken Brown wrote:

> On 12/7/2017 11:55 PM, Brian Inglis wrote:
>> On 2017-12-07 13:46, Ken Brown wrote:
>>> In my testing, 'Next' does indeed become the default button after I
>>> click
>>> outside of the textbox, but there's no visual indication of this.
>>> The MSDN page for DM_SETDEFID
>>> (https://msdn.microsoft.com/en-us/library/windows/desktop/ms645413(v=vs.85).aspx)
>>> mentions
>>> a different situation where button highlighting doesn't accurately
>>> reflect the
>>> default button.  In that case it suggests sending a BM_SETSTYLE
>>> message to
>>> change the border style.
>>> I looked at the documentation for BM_SETSTYLE, but it wasn't obvious
>>> to me what
>>> do do.
>>
>> Seems like you want to change the button state not style - checking
>> around you
>> might want to use Button_SetState macro or BM_SETSTATE message TRUE to
>> highlight, FALSE to reset:
>>
>> https://msdn.microsoft.com/en-us/library/windows/desktop/bb849168(v=vs.85).aspx 

No, 'state' is the highlight when the button is pressed, which is
different to the outline 'style' when the button is the default (ofc,
MSDN documentation is as clear as mud, as usual)

> Thanks for the suggestions, but I tried various BM_SETSTATE and
> BM_SETSTYLE messages, and I couldn't find anything that worked: 'Next'
> remained unhighlighted.

The trick here, as you might notice from the patch in my reply, is that
there's a window hierarchy involved: the IDD_CHOOSE window is embedded
in the propsheet window, which owns the 'next' control.
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH setup] Make Enter in the user URL box cause ADD instead of NEXT

Ken Brown-6
In reply to this post by Jon TURNEY
On 12/8/2017 10:48 AM, Jon Turney wrote:

> On 07/12/2017 20:46, Ken Brown wrote:
>> On 12/7/2017 1:35 PM, Jon Turney wrote:
>>> On 05/12/2017 17:32, Ken Brown wrote:
>>>> On 12/5/2017 11:03 AM, Ken Brown wrote:
>>>>> On 12/5/2017 7:58 AM, Jon Turney wrote:
>>>>>> The search textbox on the package chooser page needs the same fix.
>>>>>
>>>>> It's not immediately clear to me how to do this, since I don't know
>>>>> what the default pushbutton should be while the user is typing in
>>>>> the search box.
>>>>>
>>>>> One possibility is to convert the label "Search" to the left of the
>>>>> box to a SEARCH pushbutton, whose effect is to call
>>>>> OnTimerMessage(). If we make this the default, then pressing Enter
>>>>> will cause the search filter to immediately take effect, which is
>>>>> probably what the user expects.
>>>
>>> It seems a bit weird to have a button which automatically pushes
>>> itself half a second after you finish typing.
>>>
>>> Attached is my attempt, which (ab)uses an invisible button.
>>
>> I agree, this is better than my version.
>>
>>>> Something like the attached?  This might not be quite right, because
>>>> the previous default button is never restored.  I'm not sure how
>>>> important that is.
>>>
>>> I think it's something that should be done, if possible, so I added
>>> that.
>>
>> In my testing, 'Next' does indeed become the default button after I
>> click outside of the textbox, but there's no visual indication of this.
>
> This is interesting: if you use TAB to move the focus out of the
> textbox, then first "Clear" gets highlight (because it's a pushbutton
> and enter pushes it), TAB again and "Current is selected (but "Next"
> gets the highlight, because that's what enter pushes)
>
> If you click to move the focus, it only seems to update the highlight
> the second time you do that.
>
> Which I guess suggests we should be ensuring the highlight is drawn on
> EN_KILLFOCUS?
>
> But once I do that, it seems I need to explicitly remove as well, which
> gives the attached, incremental patch.

That seems to fix it.  Thanks.

Ken