Error Generating Surface .XLS report (C3D 2020)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
I am following along the tutorials and find the report generator for the surface report. Using the tutorial file supplied, I generated a default report in html, and doc, but the xls keeps throwing error reports ("Failed to execute 'Surface Report'). The corrupted file is created that can not be opened in Excel (2016 desktop version). Notepad views the file as pure xml (version 1.0). It appears to contain all the data in xml structure, but the format must not be compatible with Excel . I renamed to xml, and opened in Visual Studio. The document formatter hangs up on the Surface points <PntList2D> where some lines are very long (with manual text wrapping it takes 110 lines). When I manually wrapped the text, the editor properly recognized the ending tag, until the next point list. So I repeated the process counting lines. When I reduced the single line to 22 wrapped lines and one longer line, it fixed that xml comment recognition. This leads me to think the issue is length of line (the length of the remaining line is 32724 characters) The length of the failed lines are greater than 32000, one is 34242. This sounds like a bit error issue and would co-align with the 'short' integer data type limit (32768).
So if the report generator is not checking for this issue, it should. The number of points in the list makes a list of characters longer than the standard xml interpreter can handle in a single line, and simply adding a character return in the xml solved that problem. It is likely this is the problem that causes the snag in the entire conversion from raw data to xls to stop short of completion.
Also I would like to throw into the hat the fact that this system is generating doc and xls files today, when it should be generating the docx and xlsx format files instead. Perhaps the XML file data is attempting to do so, but the file extension is not correct. Also xlsx files are compressed archives, this file is not that it is uncompressed text.
Is this an expected failure (with a known work around)?
If so then why wasn't it fixed by now?
If not, then it needs to get fixed ASAP.
Thank you,
jvj