#include <pugixml.hpp>

[Sasawaws]

The current version contains this line and comment in OpenXLSX/headers/XLXmlParser.hpp

#include <external/pugixml/pugixml.hpp> // not sure why the full include path is needed within the header file

Now this builds ok but then borks when compiling against it. Changing this to

#include <pugixml.hpp>

fixes the issue.

I did have to install libpuixml-dev to make this work but I will not that #include <pugixml.hpp> is peppered through the source without the external/pugixml/pugixml.hpp kuldge and that compiles fine so I think this doesn't fix anything and simply breaks the final product.

[aral-matrix]

1. That comment is from me - I still haven't fully understood why the full path is required in this location. But the other includes without the full path - are correct, if you'll noticed they are in CPP modules
2. please define how anything can "build ok" when "breaking when compiling"?
3. It sounds to me like you modified the CMakeLists.txt, or the Makefile.GNU (if you are using that), or if you moved pugixml away from the OpenXLSX/external folder

Please ensure you have a clean copy of the repository, and do cmake . && cmake --build . then let us know here what compiler messages (if any) you are getting.

Note the README.md: do not use the Releases, they are severely outdated.

[Sasawaws]

Sorry - I can see why this was confusing!

For me either #include <pugixml.hpp> or #include <external/pugixml/pugixml.hpp> builds the library correctly so there is no need for the explicit path.

However, with external/pugixml my own code will not compile because /usr/local/include/OpenXLSX/OpenXLSX.hpp tries to #include <external/pugixml/pugixml.hpp> somewhere and it cannot be found.

The fix (#include <pugixml.hpp>) means the library builds and my own code complies (presumably using /usr/include/pugixml.hpp supplied by libpuixml-dev).

[Sasawaws]

In answer to your other questions: I pulled the latest version as a zip file from github, ran cmake, make and make install. Either way there we no build messages of interest.

When I compiled my own code it whinged about not finding external/pugixml/pugixml.hpp so I dug through the code and changed it, ran make clean, make, make install and everything was fine.

[Sasawaws]

While I'm here - from the sheets I've managed to make and from the one in Demo2 the formulae don't auto-compute on loading into libreoffice and instead the cells show as "0" until the source cell is changed and then the cell with the formula in it updates or data|calculate:recalculate hard (ctrl+shift+f9) is clicked.

I guess related to this comment? XLDocument.cpp:1368

// ===== Delete the calcChain.xml file in order to force re-calculation of the sheet
// TODO: Is this the best way to do it? Maybe there is a flag that can be set, that forces re-calculalion.
execCommand(XLCommand(XLCommandType::ResetCalcChain));

[Sasawaws]

https://stackoverflow.com/questions/18355691/set-xlsx-to-recalculate-formulae-on-open

Trying various things from here indicates that this persists regardless of the options for calcPr but omitting the value for the cell results in the cell always being recalculated so in the worksheet changing "0" -> "" means it gets automatically computed on load.

This seems to work

"../OpenXLSX/sources/XLFormula.cpp":144

// ===== If the cell node doesn't have a value child node, create it.
if (m_cellNode->child("f").empty()) m_cellNode->append_child("f");

// if (m_cellNode->child("v").empty()) m_cellNode->append_child("v"); // removed to force recalc on load <<<<<

// ===== Remove the formula type and shared index attributes, if they exist.
m_cellNode->child("f").remove_attribute("t");
m_cellNode->child("f").remove_attribute("si");

// ===== Set the text of the value node.
m_cellNode->child("f").text().set(formulaString);

// if (resetValue) m_cellNode->child("v").text().set(0); // removed to force recalc on load <<<<<

[aral-matrix]

Sorry - I can see why this was confusing!

Okay that makes more sense - so you did a full install of the library into the system folders, and then the "external" bit stopped working - which also makes sense. I will have to think about how this include from the external folder can be avoided and replaced with a proper include path. That should fix the issue.

And yes, when you install the pugixml package from your repos, that also provides the header file so that would explain how it works then.

[aral-matrix]

as for the recalculation suggestion - could you please open a separate issue for that? That way when I look into fixing this, I don't have to scroll past 4-5 unrelated comments first to find the actual discussion.

[aral-matrix]

Also, I just saw this - does that happen to work? https://github.com/troldal/OpenXLSX/blob/master/OpenXLSX/sources/XLWorkbook.cpp#L650

void XLWorkbook::setFullCalculationOnLoad()

It is not automatically invoked anywhere - and it might be a permanent flag that is undesirable for worksheets with a lot of computations - but I never tried if this at least successfully forces recalculation on load.

[Sasawaws]

Actually the explicit link was always broken for compiling my own code even before I installed the system libraries. The scripts appear to don't install your local version of pugixml.hpp anywhere and they do seem to be required. For my computer the explicit path was never required to build the library even before I install the system libraries.

(I'll open a new issue for the autocalc as suggested)

[aral-matrix]

Actually the explicit link was always broken for compiling my own code even before I installed the system libraries. The scripts appear to don't install your local version of pugixml.hpp anywhere and they do seem to be required.

Yes, that is an open issue #268 - and I should probably fix that first, then later (in preparation hopefully for packaging OpenXLSX for debian) introduce a proper dependency on pugixml and make OpenXLSX work without a local copy of pugixml

[aral-matrix]

Update (as per #268):

I think today I finally managed to properly hide the whole XLXmlParser module behind the OpenXLSX library interface.

I reworked the library (code review is still pending) to hide the pugixml header behind the wrapper header XLXmlParser.hpp and then only include the XLXmlParser from module files, but not(!) from header files.

This means that I was able to remove all pugixml include statements except for the XLXmlParser wrapper module (header and cpp files): 665310262031d8098069e1a299d9b931ac533a00 and ce2a3c99714976207c3d4ea040523f6dd23d34fe

I would appreciate very much if you could test the latest version on the development-aral branch and give me some feedback here whether this issue can be closed after all this time.