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 549249 - Auto-correction for custom format code
Auto-correction for custom format code
Status: RESOLVED FIXED
Product: libgoffice
Classification: Other
Component: General
unspecified
Other All
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2008-08-25 05:11 UTC by Reggie Chan
Modified: 2008-08-25 19:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Reggie Chan 2008-08-25 05:11:54 UTC 
Format code like "[Red];[Blue]", which used to work in gnumeric 1.6, no longer works with the gnumeric 1.8.

Referencing Excel's behavior, Excel automatically corrects the format to "[Red]General;[Blue]General". It looks more reasonable being a gnumeric 1.6 user migrating to gnumeric 1.8.
Comment 1 Andreas J. Guelzow 2008-08-25 14:04:20 UTC 
What do you mean with: "[Red];[Blue]" no longer works?
That is a valid (if useless) format code. 

For example  "[Red]--;[Blue]-" will print double red dashes or a single blue dash depending on the sign of the content. The code you are mentioning is simply skipping the dashes.
Comment 2 Morten Welinder 2008-08-25 19:08:47 UTC 
I think he means two things:

1. In 1.6.3, we treat that empty format as "General"

2. In Excel, if you enter "[red];[blue]" it gets changed into "[Red]General;[Blue]General"

Since TEXT(42,"[red];[blue]") returns "42" in Excel, it would seem that
we need to do the translation at the format-creation time.  Hence,
unlike bug 548414, this needs to be fixed at the GOFormat level.

--> goffice.
Comment 3 Morten Welinder 2008-08-25 19:31:14 UTC 
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.