After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 167297 - Formatting numerical values sometimes yields unexplainable results
Formatting numerical values sometimes yields unexplainable results
Status: RESOLVED DUPLICATE of bug 85950
Product: Gnumeric
Classification: Applications
Component: General
git master
Other All
: Normal major
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2005-02-13 20:50 UTC by Evert Verhellen
Modified: 2005-02-14 18:45 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Formatting.gnumeric (1.54 KB, application/x-gnumeric)
2005-02-13 20:51 UTC, Evert Verhellen 		Details

Description Evert Verhellen 2005-02-13 20:50:44 UTC 
Version details: 1.4.2
Distribution/Version: Fedora Core 3

When using the following numerical formatting (copied straight from Excel):

_(* #,##0.00_);_(* \(#,##0.00\);_(* "-"??_);_(@_)

I experienced unexplainable changes from a numerical value to a text value
(apparently it looks like that). I will upload a spreadsheet that contains the
following values (with the above numerical formatting on column level):

	A1: -1567.5
	A2: =$A$1*2

Cell A2 is displayed as "(3,135.00)" which means the formula works. When you
click on cell A1, press [F2], and then [Enter], you will see that cell A2
displays as "#VALUE!" instead. Somehow, the numerical value gets screwed up,
which shouldn't. I would expect that, when editing a numerical value, you see
the underlying value without any formatting, in this case it looks like you're
just editing text. This looks like a major bug. Please note that I have also
seen this in the 1.2 series.
Comment 1 Evert Verhellen 2005-02-13 20:51:13 UTC 
Created attachment 37439 [details]
Formatting.gnumeric
Comment 2 Morten Welinder 2005-02-14 18:45:23 UTC 
Both issues:

(1) On entry, the number isn't recognized
and
(2) The string isn't interpreted as a value

are caused by us only checking against the first alternative in the format.

*** This bug has been marked as a duplicate of 85950 ***