This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I'm evaluating the IntegerTextBox and I have some problems with the behaviour of the Minimum Property. Let's assume I am allowed to enter a value between 200 and 4000 the textbox has an initial value of 200 and I would like to enter a value of 1500. The following is happening: It is possible to change the value up to 2099. But as soon as I delete some digits it is not possible to enter a value anymore. So, how is this Minimum Property expected to work, and how can I use it to get it work with my scenario? Many thanks, Dominik |
|
|
Hello Dominik, Sorry for the delay in replying on this one. There was a bug in the IntegerTextBox whereby a delete was bypassing the range checks. We have now fixed this, and the fix will be included in nightly builds dated 27 Feb 2009 and above, available after about 1430 GMT from http://www.mindscape.co.nz/products/wpfelements/nightlybuilds.aspx. If you need an extension to your trial period in order to evaluate the fix, drop us a line via the contact form (http://www.mindscape.co.nz/about/contactus/) and we will provide you with an updated licence file. Once again apologies for the slow response. |
|
|
Hi Ivan, I'm testing out the IntegerTextBox and have a small problem with the Minimum property behaviour. I've set that value to 25 and now can't edit it with the keyboard. The scenario I want is that a user clicks in the field -> it's highlighted. They can then type in the number they want --> 27. They press enter, or the control looses focus. If the value is within the desired range it is kept, if however it's outside the valid range, it's set the the closest range boundary value (ie. if the user typed 5 into the field it would be set to 25, my minimum). Does this sound like an enhancement you could provide? Without that functionality the Minimum property is pretty user-unfriendly. Regards, Josh. |
|
|
So essentially the range constraints are relaxed while the control has keyboard focus, and enforced again as the control loses focus? That sounds like a nice feature. We'll see if we can get that in for you. |
|
|
Hello Josh, This functionality is now implemented and will be in nightly builds dated 28 Feb 2009 and above. To enable it, set RangeConstraintMode="OnLostFocus" on the text box. Users will then be able to type out-of-range values, but when they tab or click away, the value will be coerced to within the bounds (to the minimum if less than Minimum, to the maximum if greater than Maximum). Please let us know if you run into any problems or have any feedback. Thanks! |
|
|
Yes, thats pretty much what I'm after. Thanks. |
|
|
Great, the super quick turnaround from you guys is awesome. |
|
|
Hi Ivan, Can I ask for another slight enhancement to this control? Could you add a "ReturnPressed" RangeConstraintMode parameter that I can combine with the "OnLostFocus" parameter (maybe an extra enum value, plus a combined value so that I can apply both of them at once from a XAML control template)? Doable? Thanks, Josh. |
|
|
That sounds doable, but can I just clarify what you want before we jump in? I am not sure whether you just need "on return pressed or lost focus," or whether you really want "on return pressed" as a composable, but also usable standalone, Flags-style option. I am a bit reluctant to have a standalone "only if they press Return" option because that implies users could move away from the control while it is still out of range, which makes me nervous. However if we were to implement the OnReturnPressed mode so that it automatically included the OnLostFocus scenario (possibly naming it OnLostFocusOrReturnPressed for clarity), would that meet your needs? |
|
|
Hi Ivan, That sounds pretty logical to me. All I really care about is the OnLostFocusOrReturnPressed option to be honest, I was just thinking a bit too 'implementation detaily' when I posted the request. I can't see a situation in which I'd (or anyone really) want to have only an OnReturnPressed option. Thanks, Josh. |
|
|
Hi Josh, This is now implemented. The new mode is named OnLostFocusOrReturn. It will be included in nightly builds dated 7 Mar 2009 and above, available from about 1430 GMT. Please let us know if you run into any problems. |
|
|
Hi Ivan, Do you not think that the OnLostFocusOrReturn option might feel a little more natural if after the Return key is pressed the state of the integertextbox goes to the initial state it has when you first click on it? ie. The text is completely selected and the cursor is no longer flashing in the box. To me it feels a little unnatural the way it is, pressing enter kinda feels like saying "I'm done", and the final state of the text box doesn't really represent that in my opinion. What are your thoughts on this? Regards, Josh. |
|
|
I think this is maybe a bit application-specific. I have to admit I am kinda getting cold feet about baking in this behaviour anyway as the use of Return to say "I'm done" in a control isn't a standard Windows keystroke -- don't worry, I'm not going to back it out, I'm just saying that I don't think there's a well-defined expectation for it at the Windows level as opposed to the application level. For example, some people might expect Return to move them to the next field. Or you could argue that you should move to the next field if validation passes, but use your behaviour of staying on the text box and highlighting the entire text if validation failed and the value was reset (so the user can try again if they want). It's a bit of a tricky one -- I don't really want to add an extra event just for this interaction mode, but I don't want to bake in a particular behaviour either. As a possibility, you could try handling PreviewKeyDown (though we do mark the return key as handled, so you may need to subscribe to handled events), or deriving a class and overriding OnPreviewKeyDown, and adding your desired selection logic in that. If you go the event route you can probably wrap this up as an attached behaviour (http://www.mindscape.co.nz/blog/index.php/2009/02/01/attached-behaviours-in-wpf/) and put it in a style (obviously if you go the derived control route it is inherently wrapped up in the control). I think you would need to grab the underlying text box from the template in order to perform the selection -- we don't expose selection APIs at the moment -- but you can get the part naming conventions from the docs. Would this be an acceptable approach for you? |
|
|
Hi Ivan, Thanks for the in-depth reply. I understand your concerns, and agree with you too. I think what's making me find the standard behaviour strange is that my IntegerTextBox is wrapped within a SpinDecorator, making the behaviour in that situation a little unnatural, especially since the value is bound to a Slider control. The attached behaviour route sounds like a good way to go, thanks for the blog post. If you would like you can back out the "AndReturn" behaviour, I'll implement the whole lot as an AttachedProperty. Regards, Josh. |
|