[GH-ISSUE #148] Error generating an output .xlsx file with MSVC

gitea-mirror commented

2026-05-05 11:43:10 -06:00

Owner

Originally created by @GBangala on GitHub (Feb 14, 2018).
Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/148

Originally assigned to: @jmcnamara on GitHub.

Hello,
I'm new here, so sorry if I'm doing wrong, and sorry in advance if it's my fault for doing something wrong.
Thanks for the lib, it's truly a great tool ! 👍

I had an olderversion of it working since September 2017, but I had to rebuild it to include the new features (such as data validation) and since I recompiled the last version (at the root (master branch) of the git repo), i have trouble generating an output files.
I mean : the c++ code builds and runs well and returns no error at all (err code = '0'), but the created outputfile is named "t" instead of "tutorial.xlsx". Plus, whenever I try to name it with a relative path like "..\myRelativePath\tutorial.xlsx", no output file is created at all, and the error code is '2'.

To build the libxlsxwriter, I tried :

build ZLib v1.2.8.
or
build ZLib v1.2.11
or
use the Zlib.lib/Zlib.dll which are in the git repo (should be v1.2.8)
build libxslxwriter using cmake to generate a .sln solution to build it with MSVC (i'm targetting a Win64 plateform) by linking either Zlib1.2.8/Zlib1.2.11/preBuiltZlib.

Thanks in advance for your answers.

Best regards

Originally created by @GBangala on GitHub (Feb 14, 2018). Original GitHub issue: https://github.com/jmcnamara/libxlsxwriter/issues/148 Originally assigned to: @jmcnamara on GitHub. Hello, I'm new here, so sorry if I'm doing wrong, and sorry in advance if it's my fault for doing something wrong. Thanks for the lib, it's truly a great tool ! 👍 I had an olderversion of it working since September 2017, but I had to rebuild it to include the new features (such as data validation) and since I recompiled the last version (at the root (master branch) of the git repo), i have trouble generating an output files. I mean : the c++ code builds and runs well and returns no error at all (err code = '0'), but the created outputfile is named "t" instead of "tutorial.xlsx". Plus, whenever I try to name it with a relative path like "..\\myRelativePath\\tutorial.xlsx", no output file is created at all, and the error code is '2'. To build the libxlsxwriter, I tried : - build ZLib v1.2.8. or - build ZLib v1.2.11 or - use the Zlib.lib/Zlib.dll which are in the git repo (should be v1.2.8) - build libxslxwriter using cmake to generate a .sln solution to build it with MSVC (i'm targetting a Win64 plateform) by linking either Zlib1.2.8/Zlib1.2.11/preBuiltZlib. Thanks in advance for your answers. Best regards

gitea-mirror

2026-05-05 11:43:10 -06:00

closed this issue
added the
bug

short term
labels

gitea-mirror commented

2026-05-05 11:43:18 -06:00

Author

Owner

@jmcnamara commented on GitHub (Feb 14, 2018):

There is an issue with MSVC where filenames get truncated to one character. However, the following function in the code should take care of that: https://github.com/jmcnamara/libxlsxwriter/blob/master/src/packager.c#L48

This is optionally #defined in (with #ifdef _WIN32) so check to make sure it is being included.

@jmcnamara commented on GitHub (Feb 14, 2018): There is an issue with MSVC where filenames get truncated to one character. However, the following function in the code should take care of that: https://github.com/jmcnamara/libxlsxwriter/blob/master/src/packager.c#L48 This is optionally `#define`d in (with `#ifdef _WIN32`) so check to make sure it is being included.

gitea-mirror commented

2026-05-05 11:43:20 -06:00

Author

Owner

@GBangala commented on GitHub (Feb 14, 2018):

Hi,

Thanks for the quick answer !

I tried to look at the packager.c file and it's already defined and supposedly working.
To try it, I #define _WIN32 just before the #ifndef block but the end program behaved the same at the end.

@GBangala commented on GitHub (Feb 14, 2018): Hi, Thanks for the quick answer ! I tried to look at the packager.c file and it's already defined and supposedly working. To try it, I `#define _WIN32` just before the `#ifndef` block but the end program behaved the same at the end.

gitea-mirror commented

2026-05-05 11:43:23 -06:00

Author

Owner

@jmcnamara commented on GitHub (Feb 14, 2018):

In that case you will need to supply a sample app that demonstrates the issue along with full reproducible instructions on how to reproduce it. Otherwise l won’t be able to debug fix it.

@jmcnamara commented on GitHub (Feb 14, 2018): In that case you will need to supply a sample app that demonstrates the issue along with **full** reproducible instructions on how to reproduce it. Otherwise l won’t be able to debug fix it.

gitea-mirror commented

2026-05-05 11:43:24 -06:00

Author

Owner

@GBangala commented on GitHub (Feb 14, 2018):

Thanks for the answer.
Excuse me, as I'm still a newbie, I don't get what you want me to send :

the full code with the full build procedure pasted here (or somewhere else like pastebin) ?
the .cpp i wrote and the lib attached somewhere ?

@GBangala commented on GitHub (Feb 14, 2018): Thanks for the answer. Excuse me, as I'm still a newbie, I don't get what you want me to send : - the full code with the full build procedure pasted here (or somewhere else like pastebin) ? - the .cpp i wrote and the lib attached somewhere ?

gitea-mirror commented

2026-05-05 11:43:26 -06:00

Author

Owner

@jmcnamara commented on GitHub (Feb 14, 2018):

I’m looking more for a series of steps to follow on how to reproduce it. For example how the code was generated with Cmake. How it is imported into MSVC. How it is linked to an app.

Also, as a first step can you verify in the debugger, or via a printed, that _open_zipfile_win32() is actually being called.

@jmcnamara commented on GitHub (Feb 14, 2018): I’m looking more for a series of steps to follow on how to reproduce it. For example how the code was generated with Cmake. How it is imported into MSVC. How it is linked to an app. Also, as a first step can you verify in the debugger, or via a printed, that `_open_zipfile_win32()` is actually being called.

gitea-mirror commented

2026-05-05 11:43:29 -06:00

Author

Owner

@GBangala commented on GitHub (Feb 14, 2018):

Thanks for taking time explaining me : Ok now I get it ! I'm doing it ASAP, then.

First the debugging step : by putting printf()s all around the code, I can say : the function _open_zipfile_win32() is actually being called.

@GBangala commented on GitHub (Feb 14, 2018): Thanks for taking time explaining me : Ok now I get it ! I'm doing it ASAP, then. First the debugging step : by putting `printf()`s all around the code, I can say : the function `_open_zipfile_win32()` is actually being called.

gitea-mirror commented

2026-05-05 11:43:31 -06:00

Author

Owner

@GBangala commented on GitHub (Feb 14, 2018):

So here is my step by step process

My plateform is a Windows 10, with MSVisualStudio 2017

BUILD ZLIB V1.2.8 :

I downloaded this version on website www.zlib.net
In PowerShell
mkdir .\build
cd .\build
cmake .. -G "Visual Studio 15 2017 Win64" -DCMAKE_INSTALL_PREFIX:PATH="D:/InstallLocation/Zlib_1_2_8"
In MSVC15 through zlib.sln :
Select Win64 Debug
=> Build 'zlib.vcxproj'
=> Build 'RUN_TESTS'
=> Build 'INSTALL'
which results in no error and all files moved to "D:/InstallLocation/Zlib_1_2_8"
Select Win64 Release and do exactly the same

BUILD LIBXLSXWRITER :
In PowerShell :

git clone https://github.com/jmcnamara/libxlsxwriter.git .
mkdir .\build
cd .\build
cmake .. -G "Visual Studio 15 2017 Win64" -DCMAKE_INSTALL_PREFIX:PATH="D:/InstallLocation/LibXLSXWriter" -DZLIB_ROOT:STRING="D:/InstallLocation/Zlib_1_2_8"
In MSVC15 through xlsxwriter.sln :
Select Win64 Debug
=> Build 'xlsxwriter.vcxproj'
=> Build 'INSTALL'
which results in no error and all files moved to "D:/InstallLocation/LibXLSXWriter"
Select Win64 Release and do exactly the same

LINK MY PROJECT :
In MSVC15 :

I created a new empty project
I pasted the data_validate_8c-example code in my main
I linked it by doing so :
-> additional include directories : D:\InstallLocation\LibXLSXWriter; D:\InstallLocation\LibXLSXWriter\include;
-> additional lib directories : D:/InstallLocation/LibXLSXWriter/lib/x64/;
D:\InstallLocation\Zlib_1_2_8\lib;
-> additional dependencies : Debug\xlsxwriter.lib; zlibd.lib;
build it in Win64 Debug mode => no error
run it => no error code (returned 0)
output file is named "d" instead of "data_validate1.xlsx"

I did to put printf("debug _open_zipfile_win32()"); in the packager.c code to be sure that the function would be called :
-> rebuilt "xlexwriter.vcxproj" -> rebuilt "INSTALL"
-> rebuilt "myProj" -> run -> the printed message appears.

I think I described all I did. Do you need more informations ?

@GBangala commented on GitHub (Feb 14, 2018): **So here is my step by step process** My plateform is a Windows 10, with MSVisualStudio 2017 **BUILD ZLIB V1.2.8 :** - I downloaded this version on website www.zlib.net **In PowerShell** - `mkdir .\build` - `cd .\build` - `cmake .. -G "Visual Studio 15 2017 Win64" -DCMAKE_INSTALL_PREFIX:PATH="D:/InstallLocation/Zlib_1_2_8"` **In MSVC15** through zlib.sln : - Select Win64 Debug => Build 'zlib.vcxproj' => Build 'RUN_TESTS' => Build 'INSTALL' which results in no error and all files moved to "D:/InstallLocation/Zlib_1_2_8" - Select Win64 Release and do exactly the same **BUILD LIBXLSXWRITER :** **In PowerShell :** - `git clone https://github.com/jmcnamara/libxlsxwriter.git .` - `mkdir .\build` - `cd .\build` - `cmake .. -G "Visual Studio 15 2017 Win64" -DCMAKE_INSTALL_PREFIX:PATH="D:/InstallLocation/LibXLSXWriter" -DZLIB_ROOT:STRING="D:/InstallLocation/Zlib_1_2_8"` **In MSVC15** through xlsxwriter.sln : - Select Win64 Debug => Build 'xlsxwriter.vcxproj' => Build 'INSTALL' which results in no error and all files moved to "D:/InstallLocation/LibXLSXWriter" - Select Win64 Release and do exactly the same LINK MY PROJECT : In MSVC15 : - I created a new empty project - I pasted the data_validate_8c-example code in my main - I linked it by doing so : -> additional include directories : D:\InstallLocation\LibXLSXWriter; D:\InstallLocation\LibXLSXWriter\include; -> additional lib directories : D:/InstallLocation/LibXLSXWriter/lib/x64/; D:\InstallLocation\Zlib_1_2_8\lib\; -> additional dependencies : Debug\xlsxwriter.lib; zlibd.lib; - build it in Win64 Debug mode => no error - run it => no error code (returned 0) - output file is named "d" instead of "data_validate1.xlsx" I did to put `printf("debug _open_zipfile_win32()");` in the packager.c code to be sure that the function would be called : -> rebuilt "xlexwriter.vcxproj" -> rebuilt "INSTALL" -> rebuilt "myProj" -> run -> the printed message appears. I think I described all I did. Do you need more informations ?

gitea-mirror commented

2026-05-05 11:43:34 -06:00

Author

Owner

@jmcnamara commented on GitHub (Feb 16, 2018):

Thanks for the detailed instructions. I was able to replicate the issue.

I need to debug it but as a workaround, change the following for that zipOpen() is called instead of _open_zipfile_win32(). You can do that by changing the #ifdef _WIN32 to something non-existentialist like #ifdef _WIN32_zzzz:

https://github.com/jmcnamara/libxlsxwriter/blob/master/src/packager.c#L102

That will get your app working for non-utf8 filenames while I investigate further. Strangely the sample project that I provide doesn't have this issue: https://github.com/jmcnamara/MSVCLibXlsxWriter Note, however that that project isn't up to date with the latest release.

Anyway, I'll dig further.

@jmcnamara commented on GitHub (Feb 16, 2018): Thanks for the detailed instructions. I was able to replicate the issue. I need to debug it but as a workaround, change the following for that `zipOpen()` is called instead of `_open_zipfile_win32()`. You can do that by changing the `#ifdef _WIN32` to something non-existentialist like `#ifdef _WIN32_zzzz`: https://github.com/jmcnamara/libxlsxwriter/blob/master/src/packager.c#L102 That will get your app working for non-utf8 filenames while I investigate further. Strangely the sample project that I provide doesn't have this issue: https://github.com/jmcnamara/MSVCLibXlsxWriter Note, however that that project isn't up to date with the latest release. Anyway, I'll dig further.

gitea-mirror commented

2026-05-05 11:43:36 -06:00

Author

Owner

@jmcnamara commented on GitHub (Feb 16, 2018):

@utelle could you have look at this to see why the _open_zipfile_win32() isn't working as expected in libxlsxwriter.

@jmcnamara commented on GitHub (Feb 16, 2018): @utelle could you have look at this to see why the `_open_zipfile_win32()` isn't working as expected in libxlsxwriter.

gitea-mirror commented

2026-05-05 11:43:38 -06:00

Author

Owner

@jmcnamara commented on GitHub (Feb 16, 2018):

It looks like this may be the same issue, or at least similar, to #104

@jmcnamara commented on GitHub (Feb 16, 2018): It looks like this may be the same issue, or at least similar, to #104

gitea-mirror commented

2026-05-05 11:43:38 -06:00

Author

Owner

@jmcnamara commented on GitHub (Feb 16, 2018):

Following the clue in #104 I was able to get to this to work, unedited, by setting the following property for each of the zlib, libxlsxwriter and exe projects:

Project 
  -> Properties
    -> General
      -> Project Defaults
        -> Character Set
          -> "Use Unicode Character Set"

I'll look into how this can be enabled via cmake.

@jmcnamara commented on GitHub (Feb 16, 2018): Following the clue in #104 I was able to get to this to work, unedited, by setting the following property for each of the zlib, libxlsxwriter and exe projects: Project -> Properties -> General -> Project Defaults -> Character Set -> "Use Unicode Character Set" I'll look into how this can be enabled via cmake.

gitea-mirror commented

2026-05-05 11:43:40 -06:00

Author

Owner

@utelle commented on GitHub (Feb 16, 2018):

As you found out for yourself it is necessary to set the Unicode property for all projects. Otherwise you experience the same issue as described in #104 - the filename is passed down as a wide string, but is then interpreted as an ANSI string, usually truncating the filename to just one character.

@utelle commented on GitHub (Feb 16, 2018): As you found out for yourself it is necessary to set the Unicode property for all projects. Otherwise you experience the same issue as described in #104 - the filename is passed down as a wide string, but is then interpreted as an ANSI string, usually truncating the filename to just one character.

gitea-mirror commented

2026-05-05 11:43:42 -06:00

Author

Owner

@GBangala commented on GitHub (Feb 19, 2018):

Wow thanks for the replies ! You guys rock !
I will test it later that day as I have a few works related appointments.
I'll let you know once it's done if everything works.

@GBangala commented on GitHub (Feb 19, 2018): Wow thanks for the replies ! You guys rock ! I will test it later that day as I have a few works related appointments. I'll let you know once it's done if everything works.

gitea-mirror commented

2026-05-05 11:43:45 -06:00

Author

Owner

@GBangala commented on GitHub (Feb 19, 2018):

It works fine now ! It was all about specifying the "Unicode character set".
Thank' you very much @jmcnamara and @utelle for your help !

@GBangala commented on GitHub (Feb 19, 2018): It works fine now ! It was all about specifying the "Unicode character set". Thank' you very much @jmcnamara and @utelle for your help !

gitea-mirror commented

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

Author

Owner

@RalfKubis commented on GitHub (Mar 12, 2018):

I just ran into the same issue with VS2015, non-unicode CMake build of libxslsxwriter.

The first problem I see is that the Doxygen documentation of libxslsxwriter apparently doesn't state the expected encoding of the string arguments of its functions parameters. Does this mean that it ALWAYS has to be utf-8, especially for workbook_new(..)?

Note:
If _open_zipfile_win32() would consider the UNICODE preprocessor define and would ONLY convert to wide-string if UNICODE is defined, the later call to CreateFileA(..) would work fine.

From other issues I've reviewed, I assume that a Win32 build of libxslsxwriter ALWAYS has to be performed with the UNICODE macro being defined and is completely unverified for a non-UNICODE build.

Is that correct?

If so, then the CMAKE integration should enforce the UNICODE build.

@RalfKubis commented on GitHub (Mar 12, 2018): I just ran into the same issue with VS2015, non-unicode CMake build of libxslsxwriter. The first problem I see is that the Doxygen documentation of libxslsxwriter apparently doesn't state the expected encoding of the string arguments of its functions parameters. Does this mean that it ALWAYS has to be utf-8, especially for workbook_new(..)? Note: If _open_zipfile_win32() would consider the UNICODE preprocessor define and would ONLY convert to wide-string if UNICODE is defined, the later call to CreateFileA(..) would work fine. From other issues I've reviewed, I assume that a Win32 build of libxslsxwriter ALWAYS has to be performed with the UNICODE macro being defined and is completely unverified for a non-UNICODE build. Is that correct? If so, then the CMAKE integration should enforce the UNICODE build.

gitea-mirror commented

2026-05-05 11:43:52 -06:00

Author

Owner

@RalfKubis commented on GitHub (Mar 12, 2018):

for example like this:

elseif(MSVC) set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /MTd /O0 /Fd${CMAKE_BINARY_DIR}/${PROJECT_NAME}.pdb /DUNICODE") set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} /MT /Ox /Zi /Fd${CMAKE_BINARY_DIR}/${PROJECT_NAME}.pdb /DUNICODE") set(CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL} /MT /Zi /Fd${CMAKE_BINARY_DIR}/${PROJECT_NAME}.pdb /DUNICODE") set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO} /MT /Fd${CMAKE_BINARY_DIR}/${PROJECT_NAME}.pdb /DUNICODE") endif()

@RalfKubis commented on GitHub (Mar 12, 2018): for example like this: ` elseif(MSVC) set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} /MTd /O0 /Fd${CMAKE_BINARY_DIR}/${PROJECT_NAME}.pdb /DUNICODE") set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} /MT /Ox /Zi /Fd${CMAKE_BINARY_DIR}/${PROJECT_NAME}.pdb /DUNICODE") set(CMAKE_C_FLAGS_MINSIZEREL "${CMAKE_C_FLAGS_MINSIZEREL} /MT /Zi /Fd${CMAKE_BINARY_DIR}/${PROJECT_NAME}.pdb /DUNICODE") set(CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO} /MT /Fd${CMAKE_BINARY_DIR}/${PROJECT_NAME}.pdb /DUNICODE") endif() `

gitea-mirror commented

2026-05-05 11:43:54 -06:00

Author

Owner

@jmcnamara commented on GitHub (Mar 12, 2018):

If so, then the CMAKE integration should enforce the UNICODE build.

@RalfKubis Agreed. You should open a separate issue for this and also if you have a fix then submit a Pull Request.

@jmcnamara commented on GitHub (Mar 12, 2018): > If so, then the CMAKE integration should enforce the UNICODE build. @RalfKubis Agreed. You should open a separate issue for this and also if you have a fix then submit a Pull Request.

gitea-mirror commented

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

Author

Owner

@jmcnamara commented on GitHub (Apr 23, 2018):

Fixed on master without need for specifically setting UNICODE.

@jmcnamara commented on GitHub (Apr 23, 2018): Fixed on master without need for specifically setting UNICODE.

Rows
Columns

[GH-ISSUE #148] Error generating an output .xlsx file with MSVC #122