TreeView and stbConversion

TreeView>>stbConvert:fromVersion: has an error in the way it converts from
version 9 or earlier.

instVars := super stbConvert: instVarArray fromVersion: verInteger.
verInteger < 11
    ifTrue: [
        instVars := self stbConvertFromVersion10: instVarArray].

The first line converts from any version up to 9 using the superclass method
and stores the conversion result in instVars. The second line should then
convert this new (v9) array again if verInteger is 10 but instead it
converts the original array again. The result is that for TreeView of
stbVersion 9 or less the slots get out of sync and thing go bang. It should
read -

instVars := super stbConvert: instVarArray fromVersion: verInteger.
verInteger < 11
    ifTrue: [
        instVars := self stbConvertFromVersion10: instVars].

Regards
    Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
> TreeView>>stbConvert:fromVersion: has an error in the way it converts from
> version 9 or earlier.
>
> instVars := super stbConvert: instVarArray fromVersion: verInteger.
> verInteger < 11
>     ifTrue: [
>         instVars := self stbConvertFromVersion10: instVarArray].
>
> The first line converts from any version up to 9 using the superclass
method
> and stores the conversion result in instVars. The second line should then
> convert this new (v9) array again if verInteger is 10 but instead it
> converts the original array again. The result is that for TreeView of
> stbVersion 9 or less the slots get out of sync and thing go bang. It
should
> read -
>
> instVars := super stbConvert: instVarArray fromVersion: verInteger.
> verInteger < 11
>     ifTrue: [
>         instVars := self stbConvertFromVersion10: instVars].

Thanks (especially for the fix), #466

Blair

Blair,

The same problem occurs in IconicListAbstract>>stbConvert: fromVersion:

Regards
    Ian

Ian

You wrote in message news:[hidden email]...
>
> The same problem occurs in IconicListAbstract>>stbConvert: fromVersion:
>

Thanks, both now fixed under the same defect.

(It is possible this is behind the difficulties loading old packages, so I
have attached the patch).

Regards

Blair


begin 666 466.st
M(B,T-C8N<W0B(0T*#0HA26-O;FEC3&ES=$%B<W1R86-T(&-L87-S(&UE=&AO
M9'-&;W(A#0H-"G-T8D-O;G9E<G0Z(&EN<W1687)!<G)A>2!F<F]M5F5R<VEO
M;CH@=F5R26YT96=E<@T*"2)0<FEV871E("T@0V]N=F5R="!F<F]M(&5A<FQI
M97(@=F5R<VEO;B \26-O;FEC3&ES=$%B<W1R86-T/B!B>2!U<&1A=&EN9R!A
M;F0@86YS=V5R:6YG('1H92!A<G)A>2!O9B!I;G-T86YC90T*"79A<FEA8FQE
M<RP@:6YS=%9A<D%R<F%Y+B B#0H-"@E\(&EN<W1687)S('P-"@EI;G-T5F%R
M<R Z/2!S=7!E<B!S=&)#;VYV97)T.B!I;G-T5F%R07)R87D@9G)O;59E<G-I
M;VXZ('9E<DEN=&5G97(N#0H)=F5R26YT96=E<B \(#$P(&EF5')U93H@6VEN
M<W1687)S(#H]('-E;&8@<W1B0V]N=F5R=$9R;VU697)S:6]N.3H@:6YS=%9A
M<G-=+@T*"5YI;G-T5F%R<RX-"B$@(0T*(4EC;VYI8TQI<W1!8G-T<F%C="!C
M;&%S<R!C871E9V]R:65S1F]R.B C<W1B0V]N=F5R=#IF<F]M5F5R<VEO;CHA
M8FEN87)Y(&9I;&EN9R%P<FEV871E(2 A#0H-"B%4<F5E5FEE=R!C;&%S<R!M
M971H;V1S1F]R(0T*#0IS=&)#;VYV97)T.B!I;G-T5F%R07)R87D@9G)O;59E
M<G-I;VXZ('9E<DEN=&5G97(-"@DB4')I=F%T92 M($-O;G9E<G0@9G)O;2!E
M87)L:65R('9E<G-I;VX@/%1R9656:65W/B!B>2!U<&1A=&EN9R!A;F0@86YS
M=V5R:6YG('1H92!A<G)A>2!O9B!I;G-T86YC90T*"79A<FEA8FQE<RP@:6YS
M=%9A<D%R<F%Y+B B#0H-"@E\(&EN<W1687)S('P-"@EI;G-T5F%R<R Z/2!S
M=7!E<B!S=&)#;VYV97)T.B!I;G-T5F%R07)R87D@9G)O;59E<G-I;VXZ('9E
M<DEN=&5G97(N#0H)=F5R26YT96=E<B \(#$Q( T*"0EI9E1R=64Z(%MI;G-T
M5F%R<R Z/2!S96QF('-T8D-O;G9E<G1&<F]M5F5R<VEO;C$P.B!I;G-T5F%R
M<UTN#0H)7FEN<W1687)S(2 A#0HA5')E959I97<@8VQA<W,@8V%T96=O<FEE
M<T9O<CH@(W-T8D-O;G9E<G0Z9G)O;59E<G-I;VXZ(6)I;F%R>2!F:6QI;F<A
.<')I=F%T92$@(0T*#0H`
`
end

> The same problem occurs in IconicListAbstract>>stbConvert: fromVersion:

MoenTreeView too, from the look of the byte codes (I can't see the source).

    -- chris

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> > The same problem occurs in IconicListAbstract>>stbConvert: fromVersion:
>
> MoenTreeView too, from the look of the byte codes (I can't see the
source).

Thanks Chris, I've fixed it under the same defect.

Regards

Blair