Is gtk_spin_button_get_value_as_float() broken?



[Another message similar to this one may also appear in your inbox.  That
message is waiting in the moderator's mailbox because I tried sending it while
unsubscribed.]

Why does gtk_spin_button_get_value_as_float() sometimes return an inexact
value?  There are two cases where it does this, (1) being the most severe:

1) The user types in a number like 3.21.  gtk_spin_button_get_value_as_float()
returns 3.20999 or 3.21002.

2) The user uses the arrows and winds up on 3.21.
gtk_spin_button_get_value_as_float() returns 3.20999 or 3.21002.  This could be
excused with handwaving arguments like the actual stored value can't be visibly
represented.

The example code in testgtk.c uses

sprintf (buf, "%0.*f", spin->digits, gtk_spin_button_get_value_as_float(spin));

without any commentary as to why the result needs spin->digits at all.

The financial application I'm writing would prefer either:

1) The exact keyed in value or the visible value if the arrows were used, or
2) Only the visible value no matter how it got there.

And from an API standpoint, being forced to sprintf() a returned double value
into a buffer to get the desired value seems like a total hack to me.

For now I'm going to implement my_gtk_spin_button_get_value_as_float() which
multiplies the result of gtk_spin_button_get_value_as_float() by 10^(the
number of decimal digits), adds 0.5, casts the result back to an integer, then
divides the result by 10^(the number of decimal digits).  It's yet another
hack, but it gets the exact displayed value without any sprintf() tricks.

John

-- 
John GOTTS <jgotts linuxsavvy com>  http://linuxsavvy.com/staff/jgotts




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]