Open esophagoose opened 1 year ago
I saw this happen on one document, but the problem disappeared when I re-saved the document in a newer version of Altium.
OLE is a pretty horrible format and I honestly have no idea how to go about tracking this bug down without a sample document to work with. Do you have one that you can share?
Found one on GitHub: https://github.com/NordicPlayground/nrf52-quadcopter/blob/master/Hardware/Altium%20Designer%20files/pca20017_mcu.SchDoc
altium_js: |RECORD=41|INDEXINSHEET=6|OWNERPARTID=-1|COLOR=8388608|FONTID=1|ISHIDDEN=T|TEXT=nRF52 Quadcopter - MCU|NAME=Title|READONLYDEX=58|OWNERPARTID=-1|LOCA
with the issue being READONLYDEX=58
where the two records merge.
python: b'RECORD=41|INDEXINSHEET=6|OWNERPARTID=-1|COLOR=8388608|FONTID=1|ISHIDDEN=T|TEXT=nRF52 Quadcopter - MCU|NAME=Title|READONLYSTATE=1|UNIQUEID=GHIPKTSC'
Thanks. I'll see if I can figure out the bug.
Reading in my schematic using the demo website throws an error about invalid record type because it's mapping
payload_length
andpadding
to the middle of a record.Looking into why this happens, this is what is read in:
|RECORD=41|OWNERICORD=41|OWNERINDEX=53|OWNERPARTID=-1|COLOR=8388608|FONTID=1|TEXT=GND|NAME=HiddenNetName|UNIQUEID=TLLLFVFF
And it looks like a record is written on top of another here:
|OWNERI[NDEX...][|RE]CORD=41|
and because of this the reading lengths are off and it messes up the script. Though, this how it's written in the SchDoc, but interestingly, python's olefile package read it in correctly and reads out this:'RECORD=41|OWNERINDEX=50|INDEXINSHEET=1|OWNERPARTID=-1|LOCATION.X=820|LOCATION.Y=380|COLOR=8388608|FONTID=1|ISHIDDEN=T|TEXT=PKTIIHTP|NAME=PinUniqueId|UNIQUEID=YYMMMJRP', 'RECORD=41|OWNERINDEX=53|OWNERPARTID=-1|COLOR=8388608|FONTID=1|TEXT=GND|NAME=HiddenNetName|UNIQUEID=TLLLFVFF'
The record with id
YMMMJRP
is located earlier in the SchDoc file and right after it is anotherHEADER
record which makes me think OLE files have chunks to them that aren't being accounted for