To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=46511
User er changed the following:
What |Old value |New value
================================================================================
CC|'kohei' |'er,kohei'
--------------------------------------------------------------------------------
OS/Version|Windows XP |All
--------------------------------------------------------------------------------
Platform|Other |All
--------------------------------------------------------------------------------
------- Additional comments from [email protected] Thu Oct 1 20:25:55 +0000
2009 -------
A short glance reveals that this would work only for the default locale:
In ScDrawStringsVars::SetText()
if (static_cast<NfIndexTableOffset>(nFormat) == NF_NUMBER_STANDARD)
Casting the format index to NfIndexTableOffset is wrong anyway, if at
all this should be
NfIndexTableOffset nOffset = pFormatter->GetIndexTableOffset( nFormat );
instead. However, as the General format is always the first format for
a given locale, the shortcut to determine whether the format index is
the one for the General format of any locale would be
if (nFormat % SV_COUNTRY_LANGUAGE_OFFSET == 0)
Apart from that I have some nitpicks:
1. The approach overrides the "Decimal places" Calc option.
2. The display string may easily get a length that makes it not fit into
the current column width, resulting in ### being displayed. Users may
be confused by this. Excel automatically widens the column as long as
it has the default width, which may or may not be regarded as
favorable though. When changing the column width in Excel it adapts
the display string to a precision representable in the width.
3. Existing OOo documents will have their displayed values changed. For
fractional formula results this may be annoying, especially in
financial calculations that usually display 2 decimals.
4. If the "Precision as shown" Calc option is enabled, displayed and
calculated values will differ as the calculation still will use the
lower document standard precision.
#4 clearly is a no-no but could be easily adapted in
ScDocument::RoundValueAsShown()
#3 may be circumvented by still using ScDocOptions::GetStdPrecision()
and for newly created documents additionally have a document option that
disables this standard precision to create full precision display
strings. UI and stored documents will require this extra flag.
The GetInputLineString() approach should be changed back for that,
SvNumberFormatter::GetOutputString() already uses the precision set from
the document options. This would also resolve #1 again. Internally we
could use a special value 0xffff to flag absence of standard precision.
GetOutputString() already does similar with an arbitrary value of 300 to
switch to ImpGetOutputInputLine(), would simply have to be adapted to
the new value.
#2 may need discussion with UX whether the simple approach is
acceptable. Personally I wouldn't mind if ### were displayed instead of
having to automatically widen the column, but ...
If the precision displayed would have to change with the column width,
interaction with the "precision as shown" option would have to be
considered. This would unnecessarily complicate a solution and I would
opt for a later resolution if desired.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
