ShareSource Site »
Projects » iouyom »
iouyomBug Tracker
Summary ![[^]](/i/16x16/places/user-home.png)
Files ![[^]](/i/16x16/apps/preferences-desktop-display.png)
Screenshots ![[_]](/i/16x16/actions/document-properties.png)
Wiki ![[!]](/i/16x16/apps/kbugbuster.png)
Bug Tracker
Mercurial Repository
Actions » View tickets | Report a bug
I'll look into it. I agree it is needed for currency amounts
It will depend on wether i can convert a previous database with int values to a db with fractional values and on how well floats work in the user interface.
Comment by: Bernhard | Posted: Thursday, 29 May 2008, 10:44PM (29/05/2008)
There is now an experimental version for floats in the repository, if someone wants to test it..
But PyS60 doesn't seem to handle floats all that well.
In particular
* the appuifw Form crashes if the float is too large
* pys60 %f adds separators every 3 digits, but uses the same one as for the comma (i.e. "%f" % 20000.20 => 20.000.20)
Comment by: Bernhard | Posted: Monday, 30 June 2008, 02:23PM (30/06/2008)
Using Real Numbers in PythonS60 forms and code seems to be a real hassle.
If it's just about money ;-> , I recommend to work around the issue by creating a Category "Cents" and using integer values there.
Propably not the best of solutions, but much better than all the problems that start to creep up when you want the application to work flawlessy with non-integer values :/
Comment by: Bernhard | Posted: Sunday, 25 January 2009, 09:12PM (25/01/2009)
The Symbian C Library is just as bad as ever, and with it PyS60's floating point localisation.
However I have now finished a floating point version of IouYom that works around all floating point bugs I could find so far.
Now I need helpful testers and feedback to track down anything I might have missed.
Cheers,
Bernhard
Comment by: Bernhard | Posted: Tuesday, 11 May 2010, 06:10AM (11/05/2010)
lacking feedback it apparently took me 9 months (of then and again use of IouYom) to notice my big mistake in the custom floating point number formating function.
It's fixed now, and I suppose the issue is now closed as non-integer numbers work flawlessly now.
Project: I owe U, You Owe Me [Bug Tracker]
Summary Files Screenshots Wiki Bug Tracker Mercurial Repository Bug #192 [CLOSED]
Reason: Implemented
| Vital Bug Details | |
|---|---|
| Summery: non-integer amounts | |
| Severity: Very Low | |
| Status: | Priority: High |
| Assigned to: Nobody | Percent Complete: 100% |
| Bug Reporter | |
| Reported by: Anonymous ( on Wednesday, 21 May 2008, 05:20AM (21/05/2008) ) | |
| Bug Details | |
| Hi
I really like your application. One thing bugs me though... Could you change the amount field to accept also non integer numbers? |
|
| View History » | |
Comments
Comment by: Bernhard | Posted: Monday, 26 May 2008, 09:03PM (26/05/2008)I'll look into it. I agree it is needed for currency amounts
It will depend on wether i can convert a previous database with int values to a db with fractional values and on how well floats work in the user interface.
Comment by: Bernhard | Posted: Thursday, 29 May 2008, 10:44PM (29/05/2008)
There is now an experimental version for floats in the repository, if someone wants to test it..
But PyS60 doesn't seem to handle floats all that well.
In particular
* the appuifw Form crashes if the float is too large
* pys60 %f adds separators every 3 digits, but uses the same one as for the comma (i.e. "%f" % 20000.20 => 20.000.20)
Comment by: Bernhard | Posted: Monday, 30 June 2008, 02:23PM (30/06/2008)
Using Real Numbers in PythonS60 forms and code seems to be a real hassle.
If it's just about money ;-> , I recommend to work around the issue by creating a Category "Cents" and using integer values there.
Propably not the best of solutions, but much better than all the problems that start to creep up when you want the application to work flawlessy with non-integer values :/
Comment by: Bernhard | Posted: Sunday, 25 January 2009, 09:12PM (25/01/2009)
The Symbian C Library is just as bad as ever, and with it PyS60's floating point localisation.
However I have now finished a floating point version of IouYom that works around all floating point bugs I could find so far.
Now I need helpful testers and feedback to track down anything I might have missed.
Cheers,
Bernhard
Comment by: Bernhard | Posted: Tuesday, 11 May 2010, 06:10AM (11/05/2010)
lacking feedback it apparently took me 9 months (of then and again use of IouYom) to notice my big mistake in the custom floating point number formating function.
It's fixed now, and I suppose the issue is now closed as non-integer numbers work flawlessly now.