7.0 Issues

Peter Haworth pete at lcsql.com
Thu Feb 19 18:59:17 EST 2015 

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 <pete at 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 <eric at 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 <pete at 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 <eric at 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 <pete at 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 <
>> eric at 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 <pete at 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 at 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 at 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 at 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 at 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 at 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 at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>

More information about the use-livecode mailing list