7.0 Issues
Eric Corbett
eric at canelasoftware.com
Thu Feb 19 17:22:34 EST 2015
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
More information about the use-livecode
mailing list