StructureArray and STB

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

StructureArray and STB

Bill Schwab-2
Hi Blair,

I have been having a problem reading some "legacy" files: STB written by a
3.06 app.  Different files failed in different ways, but, in at least some
of them, there was an obvious offset problem.  It looked like an STB version
problem, but, all of the iv layouts check out: I wrote some code to log all
of that and can't find a discrepancy, at least in the named variables.

My next step was to generate an "empty" document in 3.06 and load it into
4.0.  After a few iterations trying to get the 3.06 and 4.0 verions of it to
be comparable, I found that I was able to load the 3.06 STB into 4.0.  The
real data still would not load, as one would expect - but I checked :)
Then I started adding some elements, saved 3.06 files, and loaded them into
4.0.  It didn't take long to generate a walkback.

The real data includes structure arrays, so I tried taking binary store
bytes from 3.06 into 4.0, and got a walkback.  Here's an example:

3.06:
( StructureArray length:1 elementClass:DWORD ) binaryStoreBytes
#[33 83 84 66 32 48 32 6 4 14 0 83 116 114 117 99 116 117 114 101 65 114 114
97 121 0 0 0 0 54 0 9 0 66 121 116 101 65 114 114 97 121 4 0 0 0 0 0 0 0 3 0
0 0 78 2 13 0 1 0 0 0 83 84 66 67 108 97 115 115 80 114 111 120 121 0 0 0 0
54 0 6 0 83 116 114 105 110 103 7 0 0 0 68 111 108 112 104 105 110 178 0 0 0
5 0 0 0 68 87 79 82 68 9 0 0 0]


4.0:
( StructureArray length:1 elementClass:DWORD ) binaryStoreBytes
#[33 83 84 66 32 48 32 6 5 14 0 83 116 114 117 99 116 117 114 101 65 114 114
97 121 0 0 0 0 54 0 9 0 66 121 116 101 65 114 114 97 121 4 0 0 0 0 0 0 0 3 0
0 0 78 2 13 0 1 0 0 0 83 84 66 67 108 97 115 115 80 114 111 120 121 0 0 0 0
54 0 6 0 83 116 114 105 110 103 7 0 0 0 68 111 108 112 104 105 110 178 0 0 0
5 0 0 0 68 87 79 82 68 9 0 0 0 0 0 0 0]

If I'm reading this correctly, 4.0 is writing (and reading, hence my end of
stream walkbacks) four extra bytes as compared to 3.06.  Can you confirm
that this is accurate?  Better yet<g>, can you fix it?  Appologies if I've
been looking at this too long.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: StructureArray and STB

Bill Schwab-2
Blair,

An update: StructureArray added the #owner iv and did not provide a
conversion method.  A trivial conversion method (adds owner=nil) allows me
to read my old files.  At one point, before I took any "corrective" actions,
my image bloated to 23MB from a more normal 7MB.  A panic seems to have
corrected it, but, I'm wondering if the problem had something to do with all
the partially-created structure arrays???

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: StructureArray and STB

Bill Schwab-2
In reply to this post by Bill Schwab-2
Hello all,

One thing bothered me about this:

> I have been having a problem reading some "legacy" files: STB written by a
> 3.06 app.  Different files failed in different ways, but, in at least some
> of them, there was an obvious offset problem.  It looked like an STB
version
> problem, but, all of the iv layouts check out: I wrote some code to log
all
> of that and can't find a discrepancy, at least in the named variables.

the catch being that my iv layout trap should have caught the change in
StructureArray =:0   The reason it didn't is that, at least for the files I
loaded into it, the error occured before my hacked STBDegugger recorded that
it read a StructureArray, so the iv trap never looked at StructureArray.
With the benefit of hindsight, I should have loaded the files into 3.06,
noted all classes stored in them, and then compared iv layouts between the
two versions.  As it was, my 4.0 code blew up before it could see the
problem.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]