|
From: Ivan K. <ik...@di...> - 2026-05-12 11:22:49
|
On Thu, 2 Apr 2026 16:49:35 +0300
Ivan Krylov via Liborigin-devel <lib...@li...>
wrote:
> Best I was able to find was a byte at a certain offset
> (lye_header[0x12d]) that sometimes corresponded to the sheet number,
> but it's probably a coincidence, because it has a completely
> different value in other cases.
No, not a coincidence. I took a better look at my files and realised
that in the "misordered" files, lye_header[0x12d] always contains a
permutation of [0, number of sheets). In most Origin files I found on
my PC, it indeed contains increasing integers from 0 to the number of
sheets (-1).
I wrote a macro to click the Origin window for me and reached the limit
on the number of Excel sheets (255); there's no need to look at other
bytes. It's quite easy to create a file where the sheet order doesn't
follow the window layer order by manually reordering or removing Excel
sheets in Origin.
The following patch fixes the problem for me, at the cost of
introducing "phantom" empty Excel sheets where they had been deleted:
diff --git a/OriginAnyParser.cpp b/OriginAnyParser.cpp
index bdd50e7..74e5eff 100644
--- a/OriginAnyParser.cpp
+++ b/OriginAnyParser.cpp
@@ -1538,6 +1538,12 @@ void OriginAnyParser::getLayerProperties(const string &lye_header, unsigned int
} else if (iexcel != -1) { // excel
excels[iexcel].loose = false;
+ if (lye_header_size > 0x12d) {
+ ilayer = (unsigned char)lye_header[0x12d];
+ LOG_PRINT(logfile, " Apparent layer index = %d\n", ilayer)
+ }
+ if ((unsigned int)ilayer >= excels[iexcel].sheets.size())
+ excels[iexcel].sheets.resize(ilayer+1);
if (lye_header_size > 0xD2) {
excels[iexcel].sheets[ilayer].name = lye_header.substr(0xD2, 32).c_str();
}
I'm also attaching a compressed Origin file containing two Excel books,
"Book1" with 255 sheets in order from 1 to 255 (the corresponding sheet
pointer at lye_header[0x12d] is in [0, 254]), and "Book2" ("reorder21,
remove3") with Sheet2, Sheet1, Sheet4 ... Sheet255.
--
Best regards,
Ivan
|