Localized Number input
Locked
 
|
Hi there,
anybody has any clue (or a workarround at least) to make a decent NumberPresenter wich can accept the locale format numbers? The only idea I have now is to customize a TypeConverter. Any better idea? thanks, Sebastian |
|
|
Sebastián,
> anybody has any clue (or a workarround at least) to make a decent > NumberPresenter wich can accept the locale format numbers? You could try some stuff of mine I that mentioned in this thread: http://groups.google.co.uk/group/comp.lang.smalltalk.dolphin/browse_frm/thread/89b766013ab78c24/9ce522e8d5acba32 I haven't migrated it to my real website yet but the temporary link in the post still works, and will continue to do so until I get around to publishing it "formally". -- chris [P.S. My hosting service tells me that they are encountering difficulties just now; if the links to *.metagnostic.org don't work now then they will do soon.] |
|
|
In reply to this post by Sebastián Sastre
Sebastian
I had the same problem some Month ago. In my application, which is in real use now, I use a quick and dirty solution. at www.domus-wittekind.de/hitmat/validated_numbers.zip you will find a changed version of "Validated Numbers" and a Dialog class with his model that shows the usage of the stuff. The input dialog is able to handle input of "german" numbers and even things like "1,5 * 2,15". If you need more information dont hasitate to send me a mail. Klaus |
|
|
Thank you all for your replies. Sebastian
KlausK escreveu: > Sebastian > > I had the same problem some Month ago. In my application, which is in real > use now, I use a quick and dirty solution. > at www.domus-wittekind.de/hitmat/validated_numbers.zip > you will find a changed version of "Validated Numbers" and a Dialog class > with his model that shows the usage of the stuff. The input dialog is able > to handle input of "german" numbers and even things like "1,5 * 2,15". > > If you need more information dont hasitate to send me a mail. > > Klaus |
|
|
In reply to this post by Chris Uppal-3
Chris,
I found your solution very complete. Beside that. What I found now is more behavioral than feature related. When making a interface wich should be a input for money values, is not rare to need to update per char to update other influenced values. With this locale converter (as with others) the update per char has annoying results as could be to enter the key sequence 5 and 0 and having as result '0$ 5,00' and cases similar or more complex than that. Perhaps is a little effort we make now and we all have a complete solution for this. Any ideas to improve this? regards, Sebastian Chris Uppal escreveu: > Sebastián, > > > anybody has any clue (or a workarround at least) to make a decent > > NumberPresenter wich can accept the locale format numbers? > > You could try some stuff of mine I that mentioned in this thread: > > http://groups.google.co.uk/group/comp.lang.smalltalk.dolphin/browse_frm/thread/89b766013ab78c24/9ce522e8d5acba32 > > I haven't migrated it to my real website yet but the temporary link in the post > still works, and will continue to do so until I get around to publishing it > "formally". > > -- chris > > > [P.S. My hosting service tells me that they are encountering difficulties just > now; if the links to *.metagnostic.org don't work now then they will do soon.] |
|
|
Sebastián,
> When making a interface wich should be a input for money values, is > not rare to need to update per char to update other influenced values. > With this locale converter (as with others) the update per char has > annoying results as could be to enter the key sequence 5 and 0 and > having as result '0$ 5,00' and cases similar or more complex than that. That's quite a bit harder than it looks at first sight. My preference would be just to avoid using update-per-char with formatted fields -- it just can't work correctly, and it's not clear to me that any user interface based on it can provide a better user-experience. Still, if you /do/ need that feature, then you have several GUI design issues to contend with before you can consider how to implement them. Just for example, supposing you are running with a Locale which (like the US) expects negative currency to be marked with (...) rather than a minus sign. Do you allow the user to type in a '-' ? If so do you only allow it at the start of the number, or is it OK at either end of the digits ? If you do allow it, do you instantly convert it to (), or do you leave it in place until (say) the control looses focus ? Anyway, if I were doing this (which I have no desire to do, I'm afraid), my first thought would be to start by adding a new, hidden "mode" to the localized number converter -- call it #Editing, perhaps -- which uses and recognises the Locale's decimal separator, and also understands the ()/- convention for that locale (according to whatever design choices I had made in answer to the questions above). Then I would create a new subclass of TextEdit which "knew" that its #typeconverter was a NumberToLocalizedText, and which when it acquired the focus switched the #typeconverter into #Editing mode, and when it lost focus switched it back again. Come to think of it, there should probably be at least two modes, #NumericEditing and #CurrencyEditing -- since the rules about formatting can differ depending on whether the number is a number or represents currency. Another approach would be to have two different kinds of localized number converter, one (the current one) would be used for display purposes (and when #updatePerChar is false); the other would be used while the user is actively editing a field. Again this would be best implemented with the help of a special View. That has -- for you -- the advantage that you wouldn't need to change the existing package, just add stuff of your own. A completely different -- much less general -- approach would be for your application to watch for when the one of its sub-components got focus, and react by changing the view in some way. -- chris |
|
|
I see. When reading your answer, came to my mind thet perhaps one just
can simplify things using a presenter that when is edited (per char or not) is just as a regular US formated number input, but when the focus is lost, it changes it's rendering with your localized number input. When regaining focus it can be seen as a regular US formatted number input again. That shouldn't be so difficult to implement and could get the user happy. What do you think? Sebastian Chris Uppal escreveu: > Sebastián, > > > When making a interface wich should be a input for money values, is > > not rare to need to update per char to update other influenced values. > > With this locale converter (as with others) the update per char has > > annoying results as could be to enter the key sequence 5 and 0 and > > having as result '0$ 5,00' and cases similar or more complex than that. > > That's quite a bit harder than it looks at first sight. My preference would be > just to avoid using update-per-char with formatted fields -- it just can't work > correctly, and it's not clear to me that any user interface based on it can > provide a better user-experience. > > Still, if you /do/ need that feature, then you have several GUI design issues > to contend with before you can consider how to implement them. Just for > example, supposing you are running with a Locale which (like the US) expects > negative currency to be marked with (...) rather than a minus sign. Do you > allow the user to type in a '-' ? If so do you only allow it at the start of > the number, or is it OK at either end of the digits ? If you do allow it, do > you instantly convert it to (), or do you leave it in place until (say) the > control looses focus ? > > Anyway, if I were doing this (which I have no desire to do, I'm afraid), my > first thought would be to start by adding a new, hidden "mode" to the localized > number converter -- call it #Editing, perhaps -- which uses and recognises the > Locale's decimal separator, and also understands the ()/- convention for that > locale (according to whatever design choices I had made in answer to the > questions above). Then I would create a new subclass of TextEdit which "knew" > that its #typeconverter was a NumberToLocalizedText, and which when it acquired > the focus switched the #typeconverter into #Editing mode, and when it lost > focus switched it back again. > > Come to think of it, there should probably be at least two modes, > #NumericEditing and #CurrencyEditing -- since the rules about formatting can > differ depending on whether the number is a number or represents currency. > > Another approach would be to have two different kinds of localized number > converter, one (the current one) would be used for display purposes (and when > #updatePerChar is false); the other would be used while the user is actively > editing a field. Again this would be best implemented with the help of a > special View. That has -- for you -- the advantage that you wouldn't need to > change the existing package, just add stuff of your own. > > A completely different -- much less general -- approach would be for your > application to watch for when the one of its sub-components got focus, and > react by changing the view in some way. > > -- chris |
|
|
Sebastián wrote:
> I see. When reading your answer, came to my mind thet perhaps one just > can simplify things using a presenter that when is edited (per char or > not) is just as a regular US formated number input, but when the focus > is lost, it changes it's rendering with your localized number input. > When regaining focus it can be seen as a regular US formatted number > input again. > > That shouldn't be so difficult to implement and could get the user > happy. Well, that depends on the user ;-) I think you could use the NumberToLocalizedText for that, temporarily tell it to use #mode = #Numeric and a #groupingSeparator of ''. When you've finished, set it back to #XxxCurrency and set the #groupingSeparator back to nil. That would at least continue to use the correct decimal separator for the locale. It has the added advantage (IMO) that the converter will stay in charge of the class of the numeric value (ScaledDecimal or whatever you have chosen), whereas using the "standard" numeric converter would risk having it turn the value into a Float (not a good idea for most financial applications). You would still have problems if the user actually enters the local currency symbol, or (worse) the thousands/grouping separator into the edit box, since that will not parse as a valid number for the given configuration. You could probably hack the parser to deal with that, but -- as I said before -- the real issue here is a tricky GUI design problem, not how to write the code to implement whatever design you come up with. (The test shell allows you to play with overriding things like the grouping separator.) -- chris |
«
Return to Dolphin Smalltalk
|
1 view|%1 views
| Free forum by Nabble | Edit this page |