This project has moved and is read-only. For the latest updates, please go here.

IntegerUpDown focus behaviour

Aug 24, 2011 at 4:27 PM

Hi,
Thanks for the excellent UpDown controls, which I'm hoping to be using in various projects.

I've noticed an issue with pressing 'Enter' when an UpDown control has the focus (I've only actually tried it with an IntegerUpDown but I presume this issue would apply to the others).

If you select, say, an IntegerUpDown control and then enter a number directly while the actual text box has focus, and press enter, then the value is committed and everything is as expected.

If you instead increment/decrement by clicking the up/down button as appropriate, and then press Enter - the value is incremented or decremented again. Focus appears to be left on the button last clicked, and not on the text-box. This causes problems for data-entry, as the expectation is for 'Enter' to just commit the value, as the Windows Forms one does, etc.

(I'm trying to use it in a datagrid, which may exercerbate the problem.)

I noticed there was a check-in (78147 "5 Numeric up/down controls: fixed issue with Control.Focus()") on 11th Aug - was this anything to do with this issue, or is it by design? Is there anything I can do to workaround this?

cheers,
Pete Beech

Aug 24, 2011 at 4:45 PM

This sounds like a bug.  I removed the ability to tab to the button spinners a while back, but apparently forgot all about the focus of the button spinners.  Luckily it is an easy fix.  The focus bug I fixed on Aug 11 was a separate issue.  I will check the fix in asap.  You can then get the latest source and test it out for me.

Aug 24, 2011 at 4:45 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 24, 2011 at 4:47 PM

Fixed.

Aug 24, 2011 at 4:58 PM

Thanks, that was incredibly quick! I'll try it out.

One other thing I've spotted - when the UpDown controls are disabled, the spinner buttons don't grey out as you'd expect them to. It's hard to see they're disabled, which doesn't provide the visual cues users might expect.

 

Aug 24, 2011 at 5:15 PM

They do gray out, just not as pronouced as you might be expecting.  To see what I mean, in the designer, toggle the IsEnabled property of the IntegerUpDown control and notice the style change.

Aug 24, 2011 at 5:24 PM
Edited Aug 24, 2011 at 5:28 PM

Yes, I see what you mean - the background changes - but it's the foreground colour of the buttons themselves, with the up and down arrows, that doesn't go grey - and it's this foreground colour change from black to grey which normally provides the visual cue. At least, with Windows Forms it does - and I think the built-in WPF controls too.

Pete

Aug 24, 2011 at 5:25 PM

Also, tried out the fix for the focus problem - it looks as if there is another problem, I've added a comment to the work item.

Aug 24, 2011 at 5:29 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Aug 25, 2011 at 10:31 AM

Could you reopen issue 16449 (the original one about the button focus) so it doesn't get forgotten. I hope there is a way to fix it.

Aug 25, 2011 at 1:59 PM

I've implemented a fix of sorts - I'm not sure it covers the issues you raised regarding format - and it may not cover all cases - but it may be a step in the right direction. How would I go about sending you my changes for you to have a look at?

Basically, I've added a flag (_possibleNewValueInText) and an internal value (_internalValue) into UpDownBase. The flag is to indicate that the value in the text box may have changed, and that this value should be used rather than the current 'Value' when incrementing or decrementing as a result of the OnSpin. The flag is set in OnPreviewKeyDown - possibly needs to be set somewhere else? - and reset in OnSpin.

OnSpin checks the flag, and uses a modified version of SyncTextAndValueProperties to read the current value from the text box (this is where I'm not sure if the format thing will be an issue - although it still uses ConvertTextToValue just as it would when the TextChanged event fired, so may be OK). This current value is stored in _internalValue.

The signature of the OnIncrement and OnDecrement have been changed, as follows:
 OnIncrement(bool usePassedValue, T value)

then the implementations of these do something similar to the following:

        protected override void OnIncrement(bool usePassedValue, int? latestValue)
        {
            if (usePassedValue)
            {
                Value = latestValue + Increment;
            }
            else
            {
                if (Value.HasValue)
                    Value += Increment;
                else
                    Value = DefaultValue;
            }
        }


I'm sure this is too simplistic and there are flaws with this approach, but it may be a starting point?

Aug 25, 2011 at 2:18 PM
PeteBeech wrote:

Yes, I see what you mean - the background changes - but it's the foreground colour of the buttons themselves, with the up and down arrows, that doesn't go grey - and it's this foreground colour change from black to grey which normally provides the visual cue. At least, with Windows Forms it does - and I think the built-in WPF controls too.

Although the buttons themselves are disabling correctly now, a further problem is that the actual text doesn't go grey. I had a quick look at the code, and the trigger for disabling foreground colour is certainly there in WatermarkTextBox - and if you use a standalone WatermarkTextBox, it does disable properly. But numeric controls (at least the IntegerUpDown - I'm sure the rest are the same) don't grey out the text when disabled, although the background does change. The border doesn't either - but, again, it does on a standalone WatermarkTextBox.

Aug 26, 2011 at 3:18 PM

I am not sure I will reopen the issue as this may turn out to be a "by design" answer.  I will look at this again when I am done with my day job.

Aug 29, 2011 at 3:35 PM

I fixed the color of the text when the control is disabled.

Aug 29, 2011 at 9:17 PM

That's great, thanks very much - keep up the good work!