Format function [1] is implemented in SbxValue::Format [2]. It has two sections, first of which uses SvNumberFormatter, and the second uses home-grown SbxBasicFormater. The latter handles non-numeric input, such as strings, Nulls, etc., and also special Basic string formats like "Standard" or "ttttt". (Note that the first section also handles some special formats, like "<" or "General Date".) Also the latter function handles potential numeric string cases which couldn't be converted to number using SvNumberFormatter::IsNumberFormat, but succeeded using ScanNumIntnl. This makes the implementation buggy, inconsistent, and over-engineered. The task is to unify special format string handling in the beginning of the implementation, then process Null values, check if string should be converted to number (analyzing the type of format string using SvNumberFormatter facilities) and if it can be converted, and then use the normal SvNumberFormatter processing. The implementation should drop the special processing of "@" format character used to indicate insertion of thousand separators (used currently when processing "Standard" format) and non-standard string formatting characters '!' and '\' (see bug 143183 comment 2). The fix must include an extensive unit test. [1] https://help.libreoffice.org/7.2/en-US/text/sbasic/shared/03120301.html?DbPAR=BASIC [2] https://opengrok.libreoffice.org/xref/core/basic/source/sbx/sbxscan.cxx?r=0771ac00&mo=19326&fi=660#660
(In reply to Mike Kaganski from comment #0) > Format function [1] is implemented in SbxValue::Format [2]. It has two > sections, first of which uses SvNumberFormatter, and the second uses > home-grown SbxBasicFormater. The latter handles non-numeric input, such as > strings, Nulls, etc., and also special Basic string formats like "Standard" > or "ttttt". (Note that the first section also handles some special formats, > like "<" or "General Date".) > > Also the latter function handles potential numeric string cases which > couldn't be converted to number using SvNumberFormatter::IsNumberFormat, but > succeeded using ScanNumIntnl. > > This makes the implementation buggy, inconsistent, and over-engineered. The > task is to unify special format string handling in the beginning of the > implementation, then process Null values, check if string should be > converted to number (analyzing the type of format string using > SvNumberFormatter facilities) and if it can be converted, and then use the > normal SvNumberFormatter processing. > > The implementation should drop the special processing of "@" format > character used to indicate insertion of thousand separators (used currently > when processing "Standard" format) and non-standard string formatting > characters '!' and '\' (see bug 143183 comment 2). > > The fix must include an extensive unit test. > > [1] > https://help.libreoffice.org/7.2/en-US/text/sbasic/shared/03120301. > html?DbPAR=BASIC > [2] > https://opengrok.libreoffice.org/xref/core/basic/source/sbx/sbxscan. > cxx?r=0771ac00&mo=19326&fi=660#660 VBA seems to treat "@" in a different way as you said in bug 143183 comment 2. Should the Format function be changed to match that in order for this to be considered complete? I have done some work on this in https://gerrit.libreoffice.org/c/core/+/132137 but I don't feel like it's complete yet.
(In reply to Paris Oplopoios from comment #1) > VBA seems to treat "@" in a different way as you said in bug 143183 comment > 2. > > Should the Format function be changed to match that in order for this to be > considered complete? I have done some work on this in > https://gerrit.libreoffice.org/c/core/+/132137 but I don't feel like it's > complete yet. Sorry for the late reply (missed this somehow); and sorry for not understanding the question: what specifically do you mean?