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