POI default formats Issue - apache-poi

I noticed that when a spreadsheet is created using POI, the default style set for comma style, as set when opening in Excel and clicking the button Comma Style, in Office 2007 onward, results in a format which includes the currency symbol (contrary to the definition of Comma Style in Excel).
This occurs without any format changing code in the source, so it seems to be built into POI and its effect is worksheet-wide.
By creating such a file and setting a cell to Comma Style from Excel and then doing a cell format (right click etc.), it appears to be a custom format, of the form
_("$"* #,##0.00_);_("$"* (#,##0.00);_("$"* "-"??_);_(#_)
In a normal Excel file, the expected format would have been Accounting without the currency symbol.
Is there a way to change the default styles within POI in order to correct the behavior for Comma Style?
I am testing this with NPOI 1.2.5, the NET Framework port, which i suppose is full equivalent of Apache POI form which it is derived.

With some difficulty I found the reason and I am answering as a reference.
I am using the latest stable release of NPOI. which is 1.2.5.
Checking the source(in file BuiltinFormats.cs), where standard formats are defined, I found the following
PutFormat(m, 0x2b, "_(\"$\"* #,##0.00_);_(\"$\"* (#,##0.00);_(\"$\"* \"-\"??_);_(#_)");
PutFormat(m, 0x2c, "_(* #,##0.00_);_(* (#,##0.00);_(* \"-\"??_);_(#_)");
In http://support.microsoft.com/kb/147942, which includes a list of standard formats, two entries in question are
0x2b _(* #,##0.00_);_(* (#,##0.00);_(* "-"??_);_(#_)
0x2c _($* #,##0.00_);_($* (#,##0.00);_($* "-"??_);_(#_)
This reversal in the NPOI source seems to be causing the invalid behavior of the comma style.

I had the same issue and can confirm the issue has been fixed in the 3.10 release

Related

Why does carriage return in excel is not reflected when excel value is imported in UFT

I am using Excel to compare error messages. My error message looks like this .
You have changed the values.
Do you want to continue?
I entered this value in excel using Alt+Enter, when reading this value from UFT, this carriage return is not considered.
How to include carriage return in excel so that it is visible when reading the values from UFT?
First, try to create a string formula, i.e. instead of entering the line break in the string, create a formular like
="<value>"
where <value> is the string value that you originally wanted in your cell, with the line feed contained within the quotation marks.
This might solve your issue.
But:
This is just the top of the mountain of known issues with UFTs data table API. Here is an incomplete list of additional issues (some of which, but not all, are fixed or at least improved upon in 15+):
Date values are not properly handled, especially if you are using a
non-US locale and try to consume values auto-formatted by Excel as
dates
Strange things happen if you have an .xls file. Use an .xlsx file instead. (This used to be the other way around). Note it is not only the extension I am referring to, but also the format (Excel-95 vs. more modern format)
Many formulas are unsupported Formatting behavior differentfrom what Excel would do/show
CRs and LFs are handled differently
from what Excel does
Built-in table editor is quite a silo of bugs
and antiergonomic cell values are limited in length; at the same
time, formulas have different length limits. I.e. a string in a cell is
limited to a certain maximum number of characters, but a formular
returning a string does not have that (but maybe a higher) length
limit
Because of this (and more), we auto-convert all excel sheets on the fly before when we use them in UFT after they have been updated. To do this, we are using Excel Interop (i.e. Excel´s COM automation interface) to spawn an Excel instance, create a converted version that has all formulas and formatting resolved to just string formulars, and use the converted sheets with UFTs DataTable.ImportSheet feature. Which means we unfortunately need Excel on all execution machines.
So my recommendation would be to stay away from the data table editor in UFT. Use Excel, and make sure all your edits come through to UFT in a meaningful way. If they don´t, consider a converter that creates a DataTable-compatible copy of your sheet.
Yes, I know this is suboptimal, but that´s what it has come down to after years and years of struggling with the DataTable API and UFTs "superb" built-in data table editor.

Converting text to data Apr 06, 2020 in excel

I need help in converting this text value exported in text format from software management tool "Apr 06, 2020" to data format.
I have tried various methods like text to columns then picked all of the possible data formats but nothing works. Can you please help or suggest any solution?
Your problem is a mismatch between your Windows Regional Settings (which Excel relies on in order to parse your date), and the date format in the exported file (which appears to be US-English).
You have several choices:
If the file exported from your management tool is a text or csv file, you can probably use Power Query to import the file. Select Transform then right click on the Date column and select Change type => Using Locale => and select Date and English-US.
You could change your regional settings to English(united states) while you do the import, then change them back.
If none of the dates get converted, you could try this formula:
=DATE(RIGHT(A1,4),MATCH(LEFT(A1,3),{"Jan";"Feb";"Mar";"Apr";"May";"Jun";"Jul";"Aug";"Sep";"Oct";"Nov";"Dec"},0), MID(A1,5,2))
Note that in the formula, you may need to change the commas to semicolons, or whatever your country uses to separate formula arguments
You can use below formula, Where A1 is date cell
=DATEVALUE(MID(A1,5,2)&"-"&LEFT(A1,3)&"-"&RIGHT(A1,4))

Column width style lose when converting .xls to csv

I am exporting an .xlsx document to .csv but I during that conversion I am loosing the complete style. Column width style is loosing terribly I was using Mac OS Numbers app but If i remember it correctly same issue happened with Microsoft excel ( I do not have the windows machine to cross check that for the moment).
original excel image
Exported csv image
I was wondering whether this is an application related issue or is it something wrong in general.
Did anyone face the same issue ? I do not have idea about where to begin to solve the styling issue. Some pointer will be greatly appreciated.
I added apache poi tag because I created the original excel using apache-poi
CSV stands for "Comma Separated Value".
CSV is a text file. Basically, you can open it with Excel or with a basic text editor. It is not made for storing formatting.
If you need to deal with formatted table then you have to choose another format.

Reporting Services export to Excel causes 'Repair' and removes styles

I have quite a complex SSRS report that I would like to export to Excel more or less how it looks in the web output.
Export to Excel and opening in Excel 2010 yields the following error:
Excel was able to open the file by repairing or removing the unreadable content.
Removed part: /xl/styles.xml part (Styles)
All the styling is gone from the report, so it looks terrible.
After isolation testing it I have fixed 99% of the style errors by one simple change:
Excel doesn't seem to like 'Total' cells for Row Groups within tables having no Font='' (these cells are auto-created when you create a total for a group)
Font=", 10pt, Default, Bold, Default"
Change Font to "Arial":
Font="Arial, 10pt, Default, Bold, Default"
Another thing to look for if all of your textboxes have a font name is the Format Property. I had a date field that I wanted formatted, so, in the Format field, I used =Format(Fields!CreatedDate.Value, "MM/dd/yyyy"). This worked when viewing the report, however, when exporting, received the unreadable content error. I eventually just used: MM/dd/yyyy in the format property, that solved my problem.
In my case, I fixed this by preventing a divide-by-zero.
For some weird reason, instead of failing to render a divide-by-zero, it displays the word Infinity.

Inconsistent visualization of numerical values in Excel 2007 vs the underlying xml file

I am attempting to read an Excel 2007 file (xlsx) from outside of Excel and I am finding an inconsistency that I cannot explain.
If you enter the value of 19.99 into a cell and then look at the underlying Xml document it is actually stored as 19.989999999999998. This is not the only value that does this, but it is a reasonable example. No formatting is applied in the sheet. In my example I just open a new Workbook, type in 19.99 in A1 and save the file.
I have attempted to open this simple example in both open office and Google docs and it shows 19.99 when the document is loaded.
My question is, how do I determine when to transform this value from 19.989999999999998 into 19.99 for use in other systems?
The variation between the 19.99 you entered and the 19.989999999999998 stored is the floating point variation... there will typically always be a slight discrepancy between the binary representation of a float (used internally by Excel) and the decimal used for display (and storage in the xlsx file).
Even if you haven't explicitly assigned a format to the cells, Excel applies a default formatting of "#" or "General", which typically (for numerics) displays to 2dp, applying scientific if needed. If you look at the number formatting for that cell (whether using theMS Excel front-end, or by examining the xlsx file), you should find that it is actually set to the default.

Resources