OK, well this is getting really frustrating. I changed my code to check the version and issue the 7 version of arrayencode with the extra parm with a "do" command.
I made a copy of the stack for use in LC7 and opened it in LC7. Now I get an error on the arrayencode because the stackfile version is 5.5 so it won't execute the command even though it's a perfectly valid in 7.0. I'd really like to use 7.0 for this project but I have to keep the pre 7 code base available for bug fixes. All this because the 7.0 version of arrayencode was implemented without a thought for backward compatibility. All that was needed was a preference setting for the default encoding to be used for arrayencode in 7.0. I've wasted the best part of the day trying to make this work and the arrays in question don't even contain any unicode characters! What really scares me is how many other gotchas I'll find if I go any further with this project. I will have the think carefully if it's worth the effort and hassle to try converting existing stacks over to 7 or just use it for brand new projects. On Thu Feb 19 2015 at 2:50:09 PM Peter Haworth <p...@lcsql.com> wrote: > Thanks Eric. I guess I'll have to go the "do" route. Your bug report is > 13406, I just added a comment to it. > > On Thu Feb 19 2015 at 2:22:53 PM Eric Corbett <e...@canelasoftware.com> > wrote: > >> Hi Peter, >> >> I forgot about that fact. I just checked some code in a library we use >> and indeed the arrayEncode for version 7 is wrapped in a do statement. >> >> I agree about the behavior. Mark W. made some comments to a bug report I >> submitted explaining the current functionality but I can not find it. >> >> eric >> >> >> On Feb 19, 2015, at 2:15 PM, Peter Haworth <p...@lcsql.com> wrote: >> >> > Ho Eric, >> > Spoke too soon. Your code wont compile in versions prior to 7 because >> of >> > the extra parameter. I guess I could compile it in 7 but that would >> mean I >> > would have to compile that script in 7 every time I wanted to make a >> change >> > and there's a lot of handlers in it so high probability of changes. I >> > suppose I could use a do statement (yuk). >> > >> > The more I think about this, the more it's a pretty bad backward >> > compatibility problem. I'm wondering if the dictionary entry is in fact >> > the way it was supposed to be implemented, meaning if the new parm isn't >> > present the old encoding is used. >> > >> > You only care about the new encoding if you're storing unicode data in >> an >> > array and doesn't seem like any more of an imposition to use the new >> > parameter than having to use textEncode/Decode for other unicode >> operations. >> > >> > On Thu Feb 19 2015 at 1:03:05 PM Eric Corbett <e...@canelasoftware.com> >> > wrote: >> > >> >> I think what you will have to do is this: >> >> >> >> Check the LC version; >> >> if it’s >= 7 then >> >> arrayEncode(tData,6) — force the engine to use the old arrayEncoding >> >> else >> >> arrayEncode(tData) — older versions can not have the extra parameter >> >> end if >> >> >> >> LiveCode 7 will be smart enough to decode the array either way. >> >> >> >> Eric >> >> >> >> On Feb 19, 2015, at 12:49 PM, Peter Haworth <p...@lcsql.com> wrote: >> >> >> >>> Thanks Eric, yes that does indeed help. However, I'm still confused. >> >> The >> >>> dictionary indicates that if the new parameter, version, is not >> present >> >>> then arrays are encoded the old way. None of my calls include the new >> >>> parameter so not sure how they ended up being inaccessible in pre7 >> >> versions. >> >>> >> >>> I guess the gist of my post was what else have I failed to account >> for? >> >> Is >> >>> there a document somewhere that details what code structures may need >> >>> attention when moving back and forth between LC7 and prior versions? >> I'm >> >>> guessing that anything addressing char chunks or offset would need to >> be >> >>> changed. >> >>> >> >>> On Thu Feb 19 2015 at 12:31:24 PM Eric Corbett < >> e...@canelasoftware.com> >> >>> wrote: >> >>> >> >>>> Not sure if this helps, but LiveCode 7 uses a different arrayEncoding >> >> than >> >>>> previous version due to Unicode. Check the dictionary on how to use >> >>>> arrayEncode in 7 to be able to decode in an earlier version. >> >>>> >> >>>> Eric >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> On Feb 19, 2015, at 12:16 PM, Peter Haworth <p...@lcsql.com> wrote: >> >>>> >> >>>>> I've been careful to create separate versions of my stack files and >> >>>>> Livecode Preferences folder for use when running LC 7. However, it >> >> seems >> >>>>> there other issues with compatibility. >> >>>>> >> >>>>> I save the preferences for my application in a file in the >> >>>>> /Library/Application Support folder with the following statement: >> >>>>> >> >>>>> *write* base64Encode(arrayEncode(gSettings)) to file <filepath>" >> >>>>> >> >>>>> These are then read in at startup with: >> >>>>> >> >>>>> read from file myPath until EOF >> >>>>> if it is empty then >> >>>>> put empty into gSettings >> >>>>> else >> >>>>> put arrayDecode(base64Decode(it)) into gSettings >> >>>>> end if >> >>>>> >> >>>>> Yesterday, I started working on this stack with LC7 and the prefs >> file >> >>>> was >> >>>>> saved by the LC7 version of the stack. >> >>>>> Today, I needed to go back to the non LC7 version of the stack. To >> my >> >>>>> surprise, a runtime error was thrown on the "put arrayDecode..." >> >>>> statement >> >>>>> above. The it variable looked like it contained base64 encoded >> data. >> >>>>> >> >>>>> I ran the LC7 version of the stack again and the runtime error did >> not >> >>>>> occur. >> >>>>> >> >>>>> I restored the preferences file from a Time Machine backup that I >> know >> >>>>> preceded my use of LC7, ran the application again with LC 6.6.2, and >> >> all >> >>>>> worked fine. >> >>>>> >> >>>>> So it seems that something in either the array/base64 encode/decode >> >>>>> functions changed between v6.6.2 and 7.0.1. >> >>>>> >> >>>>> I really want to use LC7 but stuff like this makes me very nervous. >> >> How >> >>>>> many other inconsistencies like this are lurking out there. >> >>>>> _______________________________________________ >> >>>>> use-livecode mailing list >> >>>>> use-livecode@lists.runrev.com >> >>>>> Please visit this url to subscribe, unsubscribe and manage your >> >>>> subscription preferences: >> >>>>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> use-livecode mailing list >> >>>> use-livecode@lists.runrev.com >> >>>> Please visit this url to subscribe, unsubscribe and manage your >> >>>> subscription preferences: >> >>>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >>>> >> >>> _______________________________________________ >> >>> use-livecode mailing list >> >>> use-livecode@lists.runrev.com >> >>> Please visit this url to subscribe, unsubscribe and manage your >> >> subscription preferences: >> >>> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> >> >> >> _______________________________________________ >> >> use-livecode mailing list >> >> use-livecode@lists.runrev.com >> >> Please visit this url to subscribe, unsubscribe and manage your >> >> subscription preferences: >> >> http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> > _______________________________________________ >> > use-livecode mailing list >> > use-livecode@lists.runrev.com >> > Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> > http://lists.runrev.com/mailman/listinfo/use-livecode >> >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
