GridExport class Pro
Exports the current view (rows after filter and sort, visible columns) as CSV or XLSX. Extension methods on GridView: grid.ExportCsv(writer), grid.ExportXlsx(stream).
public static class GridExport
- Namespace
- ArionUI.Export
- Package
- ArionUI.Export ·
dotnet add package ArionUI.Export --prerelease
Methods
ExportCsv
public static void ExportCsv<T>(this GridView<T> grid, TextWriter writer);Write the CURRENT view (filtered + sorted, visible columns in display order, grouping ignored) as CSV. Uses the culture's list separator so Excel opens it correctly; quotes/escapes per RFC 4180.
Remarks
The sink is yours, and so is the atomicity. A value of the application's that throws while being read stops the export where it is, and what has already been written stays written - in YOUR writer, which this method neither opened nor can undo. Where that matters, use GridExport.ExportCsvToFile: it owns the file and therefore can promise that a failed export leaves nothing behind.
ExportCsvToFile
public static void ExportCsvToFile<T>(this GridView<T> grid, string path, Encoding? encoding = null);Writes the current view as CSV to path, and leaves NOTHING BEHIND if it fails.
Parameters
encodingDefaults to UTF-8 with a byte-order mark, which is what Excel needs to open a CSV as Unicode.
Remarks
Why this overload exists. The overload taking a TextWriter cannot promise anything about half-written files, because the writer belongs to the caller. A value of the application's that throws part way through then leaves a file that looks complete and is not - the worst of the possible outcomes, because nothing says so. Here the file belongs to this method, so the promise can be kept.
How. Written to a sibling file in the SAME directory and moved onto the target only after the last row. Same directory on purpose: across volumes a move is a copy plus a delete, not one step, and the half file would be back. If anything throws, the sibling is deleted and an existing target is left exactly as it was - it is never truncated up front.
The exception itself is NOT caught: the application called this and has a try for it, and a library that swallows what the caller asked for is deciding in their place.
ExportXlsx
public static void ExportXlsx<T>(this GridView<T> grid, Stream stream);Write the CURRENT view (filtered + sorted, visible columns in display order) as a minimal but valid .xlsx workbook — BCL-only (ZipArchive + hand-written OOXML), no package dependency. Number columns become real numeric cells (Excel can sum them); other cells are inline strings. Streamed row-wise, so a large view does not materialize as one giant string.
A GROUPED view keeps its groups as an Excel outline: each group's header row carries its label, row count and group aggregates under their columns, its rows are one outline level deeper, and Excel's +/− folds them. Collapsed groups are exported in full — a file is not a screen.
Remarks
The sink is yours, and so is the atomicity. A value of the application's that throws while being read stops the export where it is, and what has already been written stays written - in YOUR stream, which this method neither opened nor can undo. Where that matters, use GridExport.ExportXlsxToFile: it owns the file and therefore can promise that a failed export leaves nothing behind.
ExportXlsxToFile
public static void ExportXlsxToFile<T>(this GridView<T> grid, string path);Writes the current view as an XLSX workbook to path, and leaves NOTHING BEHIND if it fails.
Remarks
See GridExport.ExportCsvToFile for why this overload exists and how the promise is kept.
