Sorry, final word on this subject. I loaded the stack, set the stackfileversion to 7.0 and saved the stack. Quit LC 7 and run again. Try to open the stack - spinning beachball of death, have to force quit.
Done have any more time to waste on this so back to good old reliable 6.6. On Thu Feb 19 2015 at 3:59:18 PM Peter Haworth <p...@lcsql.com> wrote: > 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