[GH-ISSUE #211] Wish: Slightly more flexible API #169

New issue

Closed

opened 2026-05-05 11:49:56 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 11:49:56 -06:00

Owner

Originally created by @pragmaware on GitHub (Dec 17, 2018).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/211

Originally assigned to: @jmcnamara on GitHub.

With the current API it's hard to wrap the workbook object in a freely usable C++ class.
It's also hard to gracefully handle write errors (like, say, write permission problems).

Suggested set of changes:

workbook_new() should not require a filename (it's required only when saving)
there should be a workbook_save() function that does not free the workbook
lxw_workbook_free() should be public and called workbook_free()

In this way one could create a Workbook class that wraps lxw_workbook, creates it in the constructor, frees it in the destructor and saves only when/if requested. The file can be composed and THEN the user can be asked for a filename. If the filename is not writable the user can be asked again and save can be attempted a second time. If the user aborts the procedure (by pressing cancel in the save dialog) the workbook can still be freed.

Originally created by @pragmaware on GitHub (Dec 17, 2018). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/211 Originally assigned to: @jmcnamara on GitHub. With the current API it's hard to wrap the workbook object in a freely usable C++ class. It's also hard to gracefully handle write errors (like, say, write permission problems). Suggested set of changes: - workbook_new() should not require a filename (it's required only when saving) - there should be a workbook_save() function that does not free the workbook - lxw_workbook_free() should be public and called workbook_free() In this way one could create a Workbook class that wraps lxw_workbook, creates it in the constructor, frees it in the destructor and saves only when/if requested. The file can be composed and THEN the user can be asked for a filename. If the filename is not writable the user can be asked again and save can be attempted a second time. If the user aborts the procedure (by pressing cancel in the save dialog) the workbook can still be freed.

gitea-mirror

2026-05-05 11:49:56 -06:00

closed this issue
added the
feature request

wontfix
labels

gitea-mirror commented

2026-05-05 11:50:02 -06:00

Author

Owner

@jmcnamara commented on GitHub (Dec 17, 2018):

Hi,

Thanks for the suggestion.

You may already know this, but just as background to my answer, libxlsxwriter in a port of the Python library XlsxWriter which in turn is a port of the Perl library Excel::Writer::XLSX and I wrote all three.

The APIs are consistent across all the libraries (within the limits of the different languages). So, if I change it in one I need to change it in all three.

The addition of a save() function was also requested, once or twice, for the Python library but I don't intend to add it since it could introduce a number of edge cases that weren't considered in the original design.

So for now this is a "won't fix".

P.S., for a C++ wrapper check out the following: https://github.com/Alexhuszagh/libxlsxwriterpp

John

@jmcnamara commented on GitHub (Dec 17, 2018): Hi, Thanks for the suggestion. You may already know this, but just as background to my answer, libxlsxwriter in a port of the Python library XlsxWriter which in turn is a port of the Perl library Excel::Writer::XLSX and I wrote all three. The APIs are consistent across all the libraries (within the limits of the different languages). So, if I change it in one I need to change it in all three. The addition of a `save()` function was also requested, once or twice, for the Python library but I don't intend to add it since it could introduce a number of edge cases that weren't considered in the original design. So for now this is a "won't fix". P.S., for a C++ wrapper check out the following: https://github.com/Alexhuszagh/libxlsxwriterpp John

gitea-mirror referenced this issue

2026-05-05 12:15:37 -06:00

[PR #169] [MERGED] fix #168 bump cmake minimum required version #429