Localized Number input

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Localized Number input

Sebastián Sastre
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


Reply | Threaded
Open this post in threaded view
|

Re: Localized Number input

Chris Uppal-3
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.]


Reply | Threaded
Open this post in threaded view
|

Re: Localized Number input

KlausK-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Localized Number input

Sebastián Sastre
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


Reply | Threaded
Open this post in threaded view
|

Re: Localized Number input

Sebastián Sastre
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.]


Reply | Threaded
Open this post in threaded view
|

Re: Localized Number input

Chris Uppal-3
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


Reply | Threaded
Open this post in threaded view
|

Re: Localized Number input

Sebastián Sastre
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


Reply | Threaded
Open this post in threaded view
|

Re: Localized Number input

Chris Uppal-3
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