You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm receiving spreadsheets from a customer generated by ServiceNow with cells that are very close to the 32767 character limit. This data has a large number of newlines (\n only) and when FixNewLines() gets done with it, those are expanded to \r\n and overflow the length limit.
Before offering a fix, I want to ask if it's really necessary to "fix" these at all. Excel itself has no problem with these files, and of course, "It works in Excel" is kind of the standard in the user-verse, for better or worse. But I understand there may be other cases where this was necessary, and that is why I am asking. As an aside, creating a sheet in Excel itself and examining the XML, Excel seems to put these characters unencoded into the XML(eek!), which in my understanding is incorrect XML.
Attached is a spreadsheet illustrating the problem. As-is with newlines staying as single characters, the decoded string is 32767 characters long. But when FixNewLines is done expanding \n to \r\n, the seven newlines are expanded and the total length is 32774 characters and ClosedXML throws an exception.
If it is necessary to continue to "fix" newlines, I'd like to offer a nicely compatible fix that would preserve existing functionality unless the expanded string exceeds the length limit at which point, those newlines would go unchanged. Does anyone have an opinion about my proposed change, below?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I'm receiving spreadsheets from a customer generated by ServiceNow with cells that are very close to the 32767 character limit. This data has a large number of newlines (\n only) and when FixNewLines() gets done with it, those are expanded to \r\n and overflow the length limit.
Before offering a fix, I want to ask if it's really necessary to "fix" these at all. Excel itself has no problem with these files, and of course, "It works in Excel" is kind of the standard in the user-verse, for better or worse. But I understand there may be other cases where this was necessary, and that is why I am asking. As an aside, creating a sheet in Excel itself and examining the XML, Excel seems to put these characters unencoded into the XML(eek!), which in my understanding is incorrect XML.
Attached is a spreadsheet illustrating the problem. As-is with newlines staying as single characters, the decoded string is 32767 characters long. But when FixNewLines is done expanding \n to \r\n, the seven newlines are expanded and the total length is 32774 characters and ClosedXML throws an exception.
If it is necessary to continue to "fix" newlines, I'd like to offer a nicely compatible fix that would preserve existing functionality unless the expanded string exceeds the length limit at which point, those newlines would go unchanged. Does anyone have an opinion about my proposed change, below?
Existing function:
Proposed Change:
NewlineTest.xlsx
Beta Was this translation helpful? Give feedback.
All reactions