Culture on generating computer: de-DE

• Format string: #.##0,00  -> Output correct: 1,234,567.89 (on US) and 1.234.567,89 (on German)
• Format string: #,##0.00  -> Output incorrect: 1,234,567.89 (on US) and 1.234.567,89 (on German)
• Format string: #.##0,0  -> Output incorrect: 1234567.8901 (on US) and 1234567,8901 (on German)
• Format string: #,##0.0  -> Output incorrect: 1,234,567.8 (on US) and 1.234.567,8 (on German)

The first string is an in-built string and is exported correctly. The other three strings are custom (not part of the in-built collection), are not converted to invariant culture and do not produce correct results when the file is opened in Excel.

Add support for culture-dependent number formats across consecutive calls.

Currently:

CultureInfo.CurrentCulture = new CultureInfo("de-DE");
BuiltInNumberFormats.GetNumber3(); // Returns correct: #.##0,00
CultureInfo.CurrentCulture = new CultureInfo("en-US");
BuiltInNumberFormats.GetNumber3(); // Returns wrong: #.##0,00 (should be #,##0.00)

Workaround:

var thread1 = Task.Run(() =>
{
CultureInfo.CurrentCulture = new CultureInfo("de-DE");
var format = BuiltInNumberFormats.GetNumber3();
 
Console.WriteLine($"Thread 1: {format}");
});
 
var thread2 = Task.Run(() =>
{
CultureInfo.CurrentCulture = new CultureInfo("en-US");
var format = BuiltInNumberFormats.GetNumber3();
 
Console.WriteLine($"Thread 2: {format}");
});
 
await Task.WhenAll(thread1, thread2);

The customers should have the ability to change the symbol used as a delimiter and the symbol used as a quote for a CSV document.

Provide a way to export filters.

SpreadProcessing has a method,  cellValue.GetValueAsString(format), which allows the user to apply excel format on a value and get the result. While in SpreadStreamProcessing one could get the format and the value, there is no way to get their result and this is very inconvenient when the values in question are dates.

Workaround:

foreach (ICellImporter cell in rowImporter.Cells)
{
    string value = cell.Value;
    var format = cell.Format.NumberFormat;

    var cellValueFormat = new CellValueFormat(format);
   
    ICellValue cellValue;
    CellValueFormat valueFormat;

    CellValueFactory.Create(
        value,
        worksheet,
        new CellIndex(0, 0),
        cellValueFormat,
        out cellValue,
        out valueFormat);

    var formattedValue = cellValue.GetResultValueAsString(cellValueFormat);
}

If  row has a property set on it (for example "hidden" or a style), but it does not otherwise have any cells in it, the application might run into an infinite loop. The xml will look like this:

	<sheetData>
		<row r="1" spans="1:2" x14ac:dyDescent="0.35">
			<c r="A1"><v>1</v></c>
			<c r="B1"><v>2</v></c>
		</row>
		<row r="2" spans="1:2" s="1" customFormat="1" x14ac:dyDescent="0.35"/>
	</sheetData>

The last row has formatting applied, so it is present as an element, but has no cells. This file (when the xml is not formatted) will cause an infinite loop on import.

Exception Message: "Stream does not support seeking."

I was trying to stream an XLSX document directly to a write-only stream when I noticed the XlsxWorkbookExporter implementation (or more precisely the custom ZipArchive implementation) requires the stream to be seekable.