Re: [Liborigin-devel] Reordered names for "excel" sheets

[Ivan K. <ik...@di...>]

Hello again after more than a year,

The misplaced excel sheets have finally annoyed me enough to
investigate a bit myself. Here are my findings. I'm also taking the
liberty of attaching the reproducers (<30kB; I have misplaced the
previous reproducer).

In both "ordered_right.opj" and "misordered.opj", the dataset columns
are stored with "Processed Data: IFE" (A@22, B@22, C1@22, C2@22, D1@22,
D2@22, ... D79@22, D80@22) preceding "Processed XYZ: IFE" (A@23, B@23,
C@23).

In the "ordered_right.opj" file (and in most files produced by the
fluorometer software), when readWindowElement -> readLayerElement ->
getLayerProperties is setting the Excel sheet names, the window layers
come out in the same order: "Processed Data: IFE" is stored before
"Processed XYZ: IFE". Origin and liborigin agree on the order, and all
is well.

In the "misordered.opj" file, the window layers 22 and 23 are stored in
reversed order: "Processed XYZ: IFE" precedes "Processed Data: IFE".
Origin agrees with the order of names (it shows the "Processed XYZ:
IFE" sheet before "Processed Data: IFE") but not the order of data:
somehow the "Processed XYZ: IFE" sheet must contain the columns from
@23 instead of @22, and vice versa.

If I start removing more parts of the file (e.g. delete all plots, as
in crash.opj), liborigin may crash while trying to parse the resulting
file, setting excels[iexcel].sheets[ilayer].name with ilayer ==
excels[iexcel].sheets.size(), even if it was previously possible to
read the file without problems.

Clearly, excel window layers don't always directly correspond to
spreadsheets. Should there be some sort of sheet pointer inside a
window layer header? Any ideas on where to look for it? 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.

-- 
Best regards,
Ivan