Re: 7.0 Issues

[Robert Brenstein]

On 20.02.2015 at 0:09 Uhr + Peter Haworth apparently wrote:


Done have any more time to waste on this so back to good old reliable 6.6.



Wouldn't it be simpler to just create a separate preferences file for 
the LC7-based version of the program? It seems that each version 
works with its own encoding.


RObert

___
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

Re: 7.0 Issues

[Richard Gaskin]

J. Landman Gay wrote:

 From what you've seen, it sounds like the default in 7.0 is to encode
the new way, and the dictionary is misleading. Richard G. mentioned on
the list that the default was the new encoding.


To clarify, the new method is used where it exists. :)

It works very much like stack file formats, where the default is the 
current format unless you specify otherwise.


And as with file formats, you can save in older formats from the newer 
version.


Also like file formats, apparently v6.7.x is at least somewhat aware of 
later array formats, even if it can't generate them.  It allows you to 
use the optional second argument with "arrayEncode" - it won't actually 
do anything since v6.7 doesn't understand later encoding formats, but it 
won't choke on a second param either.


This is rarely needed, for the few code bases that must run on both 6.7 
and 7.0 during the same development cycle.  It's much more common for 
development workflows to move forward, so this will be needed by very few.


I happened to be one of them, since I have a projects that has v6 
clients in the wild and uses v7 on the server, and I test my server code 
in a local ad hoc server emulator under v6.7.  Can't imagine many need 
to run the same code in both environments, but if you do it seems to 
work well provided you're using a reasonably recent v6.7 build.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: 7.0 Issues

[Peter Haworth]

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  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  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 
>> 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  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 >> >
>>> > 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  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  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 compati

Re: 7.0 Issues

[Peter Haworth]

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  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 
> 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  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 
>> > 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  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  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 "
>> >
>> > 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
>>

Re: 7.0 Issues

[Peter Haworth]

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 
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  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 
> > 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  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  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 "
> >
> > 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

Re: 7.0 Issues

[Eric Corbett]

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  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 
> 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  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 
>>> 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  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 "
> 
> 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.r

Re: 7.0 Issues

[Peter Haworth]

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 
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  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 
> > 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  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 "
> >>>
> >>> 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
>
__

Re: 7.0 Issues

[Peter Haworth]

Thanks Eric and Jacque.  I entered QCC report 14639.  I altered my code to
do as you suggest Eric.

I wonder how this affects how an array variable is stored in a custom
property?  As I understand it, the variable is automatically array encoded
if you do something like "set the cArray of me to tArray" and decoded when
you get it back out of the cProp.  Personally I only use cProps for stuff
that doesn't need to survive across runs of LC so wouldn't be affected by
any changes in that area but others may not be so lucky.

On Thu Feb 19 2015 at 1:18:58 PM J. Landman Gay 
wrote:

> On 2/19/2015 2:49 PM, Peter Haworth wrote:
> > 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.
>
>  From what you've seen, it sounds like the default in 7.0 is to encode
> the new way, and the dictionary is misleading. Richard G. mentioned on
> the list that the default was the new encoding. We should clear that up,
> it's going to affect me too eventually.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> 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

Re: 7.0 Issues

[J. Landman Gay]

On 2/19/2015 2:49 PM, Peter Haworth wrote:

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.


From what you've seen, it sounds like the default in 7.0 is to encode 
the new way, and the dictionary is misleading. Richard G. mentioned on 
the list that the default was the new encoding. We should clear that up, 
it's going to affect me too eventually.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: 7.0 Issues

[Eric Corbett]

Additionally,

The dictionary may be a bit inaccurate. In LC 7, if there is no version, 
arrayEncode uses the encoding for the version you are on, LC 7 encoding. So, if 
LC 8 has different encoding than 7, LC 8 will use LC 8 encoding when no version 
is specified.

Eric

On Feb 19, 2015, at 12:49 PM, Peter Haworth  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 
> 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  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 "
>>> 
>>> 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

Re: 7.0 Issues

[Eric Corbett]

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  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 
> 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  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 "
>>> 
>>> 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

Re: 7.0 Issues

[Peter Haworth]

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 
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  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 "
> >
> > 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

Re: 7.0 Issues

[Eric Corbett]

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  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 "
> 
> 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

7.0 Issues

[Peter Haworth]

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 "

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

Re: 7.0 Issues

[Peter M. Brigham]

On Mar 28, 2014, at 7:51 PM, Bob Sneidar wrote:

> Not sure about the inserting of pages, but you can store and “reassemble” a 
> pdf by opening it as read binary, reading it into a variable, then saving the 
> variable either as a property or stored in a database, or even encrypted in a 
> file on the HD. (Not sure what the app would be for that…) I’ve often thought 
> of storing my PDF forms in a database this way instead of on the HD. 

Richard Gaskin's fwPack/fwUnPack functions make this easy.

-- Peter

Peter M. Brigham
pmb...@gmail.com
http://home.comcast.net/~pmbrig


-

function fwPack pData, pPassword, pEncryptionMethod
   -- fwPack/fwUnPack
   -- based on routines by Richard Gaskin, Fourth World Software
   
   -- Generic functions for packing data for Internet transmission or storage,
   --with an optional modest level of password-protected security.
   --
   -- In the simplest form, fwPack() compresses data with gzip and
   --then encods it with Base64 for robust storage or transmission.
   --
   -- Data can be optionally protected by supplying a password and
   --an encryption method to the fwPack() function,
   --and subsequently the same password to the fwUnPack() function
   -- pEncryptionMethod = "00" -- no encryption, just compress it
   -- pEncryptionMethod = "01" uses MD5digest -- fast but only moderately secure
   -- pEncryptionMethod = "02" uses SHA1digest -- more secure. However:
   -- DO NOT USE THIS ALGORITHM IF YOU REQUIRE INDUSTRIAL-STRENGTH ENCRYPTION.
   
   -- if no password supplied, defaults to no encryption
   -- if password supplied but no encryption method specified,
   --defaults to MD5digest if LC version < 4.6
   --otherwise defaults to SHA1digest
   
   -- inverse function is fwUnPack()
   
   -- requires fwUnpack(), _doXor()
   --_doXor() is a private function
   
   if pPassword is empty then
  put "00" into pEncryptionMethod
  -- no encryption
   else if pEncryptionMethod = empty then
  -- password supplied but pEncryptionMethod unspecified,
  -- default to SHA1digest if possible:
  put the version into tVersion
  replace "." with empty in tVersion
  put "." after char 1 of tVersion
  put tVersion >= 4.6 into canUseSHA -- SHA1 only available with LC ≥ 4.6
  if canUseSHA then
 put "02" into pEncryptionMethod
  else
 put "01" into pEncryptionMethod
  end if
   end if
   switch pEncryptionMethod
  case "00"
 -- just compress:
 put compress(pData) into dataOut
 break
  case "01"
 -- compress then scramble with MD5-encrypted password:
 put compress(pData) into pData
 put md5digest(pPassword) into tKeyString
 put _doXor(pData,tKeyString) into dataOut
 break
  case "02"
 -- compress then scramble with SHA1-encrypted password:
 put compress(pData) into pData
 put sha1digest(pPassword) into tKeyString
 put _doXor(pData,tKeyString) into dataOut
 break
   end switch
   -- mark with encryption method:
   put pEncryptionMethod before dataOut
   -- Convert to common low ASCII:
   return base64encode(dataOut)
end fwPack

function fwUnPack pData, pPassword
   -- fwPack/fwUnPack
   -- based on routines by Richard Gaskin, Fourth World Software
   
   -- Generic functions for packing data for robust internet transmission or 
storage,
   --with an optional modest level of password-protected security.
   --
   -- fwPack() compresses data with gzip, optionally encrypts it with a 
password,
   --then encodes it with Base64.
   --
   -- fwUnPack() will unpack (and decrypt as needed) data compressed with 
fwPack()
   
   -- requires fwPack(), _doXor()
   --_doXor() is a private function
   
   -- Convert from base64 back to binary:
   put base64decode(pData) into pData
   -- Check and remove password-protection flag:
   put char 1 to 2 of pData into tEncryptionMethod
   delete char 1 to 2 of pData
   --
   switch
  case tEncryptionMethod = "00" --no encryption
 put pData into dataOut
 break
  case tEncryptionMethod = "01" -- MD5
 -- Get MD5 digest:
 put md5digest(pPassword) into tKeyString
 put _doXor(pData,tKeyString) into dataOut
 break
  case tEncryptionMethod = "02" -- SHA1
 -- get SHA1 digest
 try
put sha1digest(pPassword) into tKeyString
 catch tErr
answer "You must be running LiveCode version 4.6 or higher!" as 
sheet
exit to top
 end try
 put _doXor(pData,tKeyString) into dataOut
 break
   end switch
   -- Attempt to decompress data, throwing an error if not valid:
   try
  put decompress(dataOut) into clearData
   catch errNo
  answer "Wrong password" as sheet
  exit to top
   end try
   return clearData
end fwUnPack

private function _doXor pData,tKeyString
   -- utility function for fwPack(), fwUnPack(

Re: 7.0 Issues

[Bob Sneidar]

Not sure about the inserting of pages, but you can store and “reassemble” a pdf 
by opening it as read binary, reading it into a variable, then saving the 
variable either as a property or stored in a database, or even encrypted in a 
file on the HD. (Not sure what the app would be for that…) I’ve often thought 
of storing my PDF forms in a database this way instead of on the HD. 

Bob


On Mar 21, 2014, at 19:07 , Dr. Hawkins  wrote:

> On Fri, Mar 21, 2014 at 3:11 PM, Fraser Gordon 
> wrote:
> 
>> If I'm not careful, we might end up with Tex re-implemented inside the
>> LiveCode engine.
>> 
> 
> If this would let me manipulate pdf in livecode, I'd be all for it.  At the
> moment, I need to have a latex installation to run the pdf tools (jar).
> And all I need is to be able to reassemble/insert pages into another pdf
> file.  (being able to display a page would be nice, too . . .)
> 
> 
> 
> -- 
> Dr. Richard E. Hawkins, Esq.
> (702) 508-8462
> ___
> 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

Re: 7.0 Issues

[Mark Wieder]

Peter Haworth  writes:

> Definitely agree with that but there seems to be some confusion about
> whether that setting is working or not in 7.0.  Haven't had time to check
> it out myself.

I don't think it's just a 7.0 thing. I've had problems with the
stackFileFormat now being respected in the past, and that's why I set it
explicitly right before saving if I'm going to need to maintain it. I think
it probably just hasn't come up as an issue for you before because you
haven't been trying to maintain backward compatibility back to the 2.4 format.

-- 
 Mark Wieder
 ahsoftw...@gmail.com




___
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

Re: 7.0 Issues

[Peter Haworth]

This issue has almost come full circle for me.  The best thing to come out
of it for me was fixing lcStackBrowser to not save itself so it's not
affected by the 7.0 format, but I'm glad it developed into a discussion,
and possible solution, for the LC plugin mechanisms.

Another thing I learned from it is that the 7.0 User Extensions setting is
separate from prior versions.  I haven't been able to find any mention of
that in the release notes and it really seems like a key piece of
information for folks who want to do their community service in testing 7.0.

Is that unique to 7.0 or do all versions have their own separate User
Extensions setting?

Ironically, I'm blocked from testing lcStackBrowser with 7.0 because of two
serious bugs, one during initial compile on a show with visual effect
command, and another during execution on an arraydecode statement.  QCC
looking into them.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Sun, Mar 23, 2014 at 7:21 PM, Mark Wieder  wrote:

> Jacque-
>
> Sunday, March 23, 2014, 7:04:58 PM, you wrote:
>
> >> Jacque - did you enter a feature request?
>
> > No, but if you have time feel free. I like Mark Wieder's suggestion too.
>
> It's not an either/or thing.
> Call me crazy, but I think if you set the IDE preference to preserve
> stack file format, the stack file format should be preserved.
>
> --
> -Mark Wieder
>  ahsoftw...@gmail.com
>
> This communication may be unlawfully collected and stored by the National
> Security Agency (NSA) in secret. The parties to this email do not
> consent to the retrieving or storing of this communication and any
> related metadata, as well as printing, copying, re-transmitting,
> disseminating, or otherwise using it. If you believe you have received
> this communication in error, please delete it immediately.
>
>
> ___
> 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

Re: 7.0 Issues

[Peter Haworth]

On Sun, Mar 23, 2014 at 6:40 PM, Mark Wieder  wrote:

> Did I miss anything?


Not that I can think of.  It also has the advantage of working with
existing plugins without the need to change them.

That's what I had in mind a few emails back when I suggested using the
Prefs file, although hadn't thought it through as thoroughly as you.  I
think Richard had some concerns about that methodology though...

Enhancement request?

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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

Re: 7.0 Issues

[Peter Haworth]

Thanks Mark, you beat me to it.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Sun, Mar 23, 2014 at 7:39 PM, Mark Wieder  wrote:

> Now filed as bug^H^H^Henhancement request 12004:
>
> http://quality.runrev.com/show_bug.cgi?id=12004
>
> --
> -Mark Wieder
>  ahsoftw...@gmail.com
>
> This communication may be unlawfully collected and stored by the National
> Security Agency (NSA) in secret. The parties to this email do not
> consent to the retrieving or storing of this communication and any
> related metadata, as well as printing, copying, re-transmitting,
> disseminating, or otherwise using it. If you believe you have received
> this communication in error, please delete it immediately.
>
>
> ___
> 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

Re: 7.0 Issues

[Peter Haworth]

On Sun, Mar 23, 2014 at 7:23 PM, Mark Wieder  wrote:

> Ah... that's another thing that I do. If I ever have to do a "save
> stack" operation I make sure to set the stackFileFormat before calling
> that. That way I can ensure backward compatibility.
>

Yep, I've added that to my code just in case there's any other rogue saves
I've missed!  Hopefully once you set it, it stays that way until you reset
it.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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

Re: 7.0 Issues

[Peter Haworth]

Hi Mark,
Definitely agree with that but there seems to be some confusion about
whether that setting is working or not in 7.0.  Haven't had time to check
it out myself.

On Sun, Mar 23, 2014 at 7:21 PM, Mark Wieder  wrote:

> Call me crazy, but I think if you set the IDE preference to preserve
> stack file format, the stack file format should be preserved.
>



Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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

Re: 7.0 Issues

[Mark Wieder]

Mats-

Monday, March 24, 2014, 5:13:15 AM, you wrote:

> For my plugins I'm leaning towards your use of a plain txt, written
> in a format that could easily be read and edited. I think pref files
> should be "plain English LiveCode" wherever possible.

Not sure about "English", but key:value pairs are my choice.

> I also think there is need to save multi-level array data to pref files.
> Not sure what would be best approach for that though. I've done 
> some very basic testing and there seems to be very little difference
> in size between using arrayEncode to save as a bin string and 
> parsing the array to save as a plain text that could be read and edited.
> Any thoughts here?

JSON? I usually lean in favor or human-readable vs machine-readable
formats, but probably what matters is just something that works for
you.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

RE: 7.0 Issues

[Mats Wilstrand]

Mark,

Thanks for sharing your thoughts on this. It is much appreciated.
For my plugins I'm leaning towards your use of a plain txt, written 
in a format that could easily be read and edited. I think pref files 
should be "plain English LiveCode" wherever possible. 

I also think there is need to save multi-level array data to pref files. 
Not sure what would be best approach for that though. I've done 
some very basic testing and there seems to be very little difference 
in size between using arrayEncode to save as a bin string and 
parsing the array to save as a plain text that could be read and edited. 
Any thoughts here?

For rIDE the situation is a little different as it started out as a plugin
but is now evolving towards an independent IDE of itself. If there is an 
interest, rIDE could now be used to test new community driven features
like the ones you, Jaque and Richard are discussing for having the IDE
handling the preferences of plugins.

Best,
Mats


> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
> Behalf Of Mark Wieder
> Sent: den 23 mars 2014 17:20
> To: How to use LiveCode
> Subject: Re: 7.0 Issues
> 
> Mats-
> 
> Sunday, March 23, 2014, 4:10:28 AM, you wrote:
> 
> > As rIDE has saved itself upon closing, I too now only have two feet.
> > I will change this for rIDE 4.0. I ask for guidance and opinions here
> > on what would be best practice and the pros and cons of different
> approaches?
> 
> I don't know about "best", but here are some techniques I've adopted (and
> the changes in my behavior are a direct result of the changing file format
and
> the need to maintain compatibility with earlier
> versions):
> 
> When I work on a plugin stack I use LC 4.6.4, as this is the last version
to use
> the 2.4 format natively. That way when I save a plugin stack's changes I
can
> be sure that the format hasn't changed. If I didn't need to maintain
> compatibility back to earlier versions I could use a later LC version, but
in any
> event the native format of the selected version of LiveCode is what's
> important.
> 
> I save a preferences file in the plugin directory and write any values I
want to
> remain persistent into that file. This replaces my previous behavior of
setting
> custom properties and saving the stack. In general I save information into
this
> text file in the format
> 
> property value
> 
> so that it can also be edited by any text processor if necessary.
> Property names are single words, no spaces or punctuation.
> 
> I have somewhat standardized boilerplate routines that read the
> preferences file on opening the stack and set plugin stack properties
> accordingly. Preference file contents are written when necessary (when one
> of them changes; or in the case of a preferences panel, when the Save
> button is clicked rather than the Cancel button). I think GLX2 still saves
all its
> settings on quitting, but I'm too lazy to check right at the moment.
> 
> I no longer use the save-stack-and-revert trick to update a running plugin
> stack because of the problem with maintaining version and format
> compatibility.
> 
> --
> -Mark Wieder
>  ahsoftw...@gmail.com
> 
> This communication may be unlawfully collected and stored by the National
> Security Agency (NSA) in secret. The parties to this email do not consent
to
> the retrieving or storing of this communication and any related metadata,
as
> well as printing, copying, re-transmitting, disseminating, or otherwise
using it.
> If you believe you have received this communication in error, please
delete it
> immediately.
> 
> 
> ___
> 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

Re: 7.0 Issues

[Mark Wieder]

Now filed as bug^H^H^Henhancement request 12004:

http://quality.runrev.com/show_bug.cgi?id=12004

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

Re: 7.0 Issues

[Mark Wieder]

Pete-

Sunday, March 23, 2014, 10:37:28 AM, you wrote:

> It seems there was a stray "save stack" lurking in my code.

Ah... that's another thing that I do. If I ever have to do a "save
stack" operation I make sure to set the stackFileFormat before calling
that. That way I can ensure backward compatibility.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

Re: 7.0 Issues

[Mark Wieder]

Jacque-

Sunday, March 23, 2014, 7:04:58 PM, you wrote:

>> Jacque - did you enter a feature request?

> No, but if you have time feel free. I like Mark Wieder's suggestion too.

It's not an either/or thing.
Call me crazy, but I think if you set the IDE preference to preserve
stack file format, the stack file format should be preserved.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

Re: 7.0 Issues

[J. Landman Gay]

On 3/23/14, 5:05 PM, Peter Haworth wrote:

Perhaps Jacque's suggestion of preserving the stack file version when a
plugin is saved is the best solution.

Jacque - did you enter a feature request?


No, but if you have time feel free. I like Mark Wieder's suggestion too.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: 7.0 Issues

[Mark Wieder]

Scott-

Sunday, March 23, 2014, 4:35:50 PM, you wrote:

> It would be a bit of a chore to have to include a separate "default prefs"
> file with each plugin, but I imagine one could write a "first launch"
> script as part of their plugin's startup that checks to see if its
> configuration stuff is where it should be, and if not, writes a new file.

I like this. Or at least a version of this:

In the IDE on first launch (i.e., there's a new plugin in the plugins
folder but there's no corresponding entry in the prefs file:

The load handler in the IDE would check the plugin for a cREVLoadInfo
preference (this would previously have been taken care of on the
plugin developer's machine through a variation of the existing Plugin
Settings system). If it's there then the IDE sets an entry in the
prefs file. If not the IDE creates a default entry for the plugin in
the prefs file *and doesn't set custom prefs in the plugin*.

Thereafter on each launch of the IDE the prefs are read from the prefs
file, and the custom prefs in the plugin are ignored.

There should be an option in the Plugin Settings dialog to reset the
plugin's settings to the plugin default, and preference settings for
plugins that are no longer in the plugins folder are ignored.

This also enables the plugin stack names to be retrieved from the
plugin preferences file after their initial instantiation.

Did I miss anything?

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

Re: 7.0 Issues

[Scott Rossi]

If you're referring to LiveCode settings that determine how to manage the
plugin (i.e. cREVLoadInfo), it would be good if this info was stored
outside the plugin.  But obviously it needs to be configurable on the
author's side, as well as the user's side, and somehow loaded in the
user's LiveCode installation.  Maybe you (the developer) want some plugins
to open normally, maybe some invisibly, maybe some just to sit in the
plugins folder without launching.

(Not trying to get in a debate on what is the correct way to develop a
plugin, just sayin'  :-)


It would be a bit of a chore to have to include a separate "default prefs"
file with each plugin, but I imagine one could write a "first launch"
script as part of their plugin's startup that checks to see if its
configuration stuff is where it should be, and if not, writes a new file.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 3/23/14 12:23 PM, "Richard Gaskin"  wrote:

>For the long term, should plugin settings be stored separately from the
>plugin itself, so that the plugin isn't modified?
>
>This raises many question. Desirable, but not simple.



___
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

Re: 7.0 Issues

[Peter Haworth]

Perhaps Jacque's suggestion of preserving the stack file version when a
plugin is saved is the best solution.

Jacque - did you enter a feature request?

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Sun, Mar 23, 2014 at 2:23 PM, Richard Gaskin
wrote:

> Peter Haworth wrote:
>
>> As for the plugin settings, wouldn't storing them in the prefs file be the
>> appropriate place?
>>
>
> What happens when a plugin is moved or renamed, or updated, or any number
> of other things that can happen.
>
> Binding the data to the file is useful, but since it requires saving the
> file it's a problem.
>
> But managing a list of plugin files and keeping it sync is another
> problem.  Not necessarily intractable, perhaps even necessary, but not code
> I'd enjoy writing. ;)
>
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
> ___
> 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

Re: 7.0 Issues

[Richard Gaskin]

Peter Haworth wrote:

As for the plugin settings, wouldn't storing them in the prefs file be the
appropriate place?


What happens when a plugin is moved or renamed, or updated, or any 
number of other things that can happen.


Binding the data to the file is useful, but since it requires saving the 
file it's a problem.


But managing a list of plugin files and keeping it sync is another 
problem.  Not necessarily intractable, perhaps even necessary, but not 
code I'd enjoy writing. ;)


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: 7.0 Issues

[Peter Haworth]

On Sun, Mar 23, 2014 at 12:23 PM, Richard Gaskin  wrote:

> For v7 I've made a separate copy of my Plugins folder, and thankfully the
> team had for foresight to maintain a separate Prefs file, so that works for
> now.
>
> For the long term, should plugin settings be stored separately from the
> plugin itself, so that the plugin isn't modified?
>

I didn't know there was a separate prefs file for 7.0, that's good to know.

As for the plugin settings, wouldn't storing them in the prefs file be the
appropriate place?

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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

Re: 7.0 Issues

[Peter Haworth]

On Sun, Mar 23, 2014 at 12:22 PM, J. Landman Gay
wrote:

> That's an iffy explanation for what I meant. Version 2.6.1 was the last
> release before 2.7. What they're trying to say is that version 2.7 changed
> the file format and if you save in 2.7 then version 2.6.1 won't open it any
> more. Back then, the only other file format was the 2.4 earlier one, which
> all files created prior to 2.7 were using.
>
> It's easier to think of it in the other direction: the numbers are the
> changeover version of the file format, and engines earlier than that number
> won't open files saved in later versions.
>
> And yeah, the entry apparently hasn't been updated since 2.7 when the
> "stackFileVersion" syntax was introduced. We've had 5.5 since then and now
> 7.0. Same rules apply though.
>

Yeah, I get it now, it just seems an awkward way to express it.

I still think it would help if the "Livecode stack" format in the dropdown
menu of the Save dialog included the stack file version like the "Legacy
stack" entries do.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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

Re: 7.0 Issues

[Peter Haworth]

On Sun, Mar 23, 2014 at 12:10 PM, Richard Gaskin  wrote:

> Other than by reading the stack files, how could the display names be
> obtained?


I can't think of a way but maybe the the plugins menu could use the stack
file name (without the extension) instead of the stack name. Most of the
plugins I use have their filename the same as their stack name, although
I'm sure there are some that wouldn't fit that mould.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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

Re: 7.0 Issues

[Peter Haworth]

On Sun, Mar 23, 2014 at 11:14 AM, Mark Wieder wrote:

> Ack! Yes, you're right. I try not to mess with the Plugin Settings
> menu at all. Ever. And if I do have to open it, I do it in LC 4.6.4.
>

Yeah, I'm the same (except I use 5.5.4).

Problem is though that I send out lcStackBrowser with the mode set to
modeless and to not load at startup and I'm pretty sure some folks change
one or both of those settings.  If they do that in 7.0 and don't have the
preference set to preserve the stack file version, it will become a 7.0
stack and no longer recognized by anything prior to 7.0.

Remind me again why I decided to get into the plugin business!


Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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

Re: 7.0 Issues

[Richard Gaskin]

J. Landman Gay wrote:

On 3/23/14, 2:23 PM, Richard Gaskin wrote:

For the long term, should plugin settings be stored separately from the
plugin itself, so that the plugin isn't modified?


Probably. But for now the most expedient solution would be a feature
request in the QCC asking RR to preserve the file format in their plugin
handlers. That shouldn't be too hard for them to do, and it's a good
time to request it since v. 7.0 is in active development.


I wonder if that should be extended to all stacks - whenever any IDE 
action would save changes to a stack file, it could check the stack file 
version of the stack and if saving would change it the user would be 
asked what version to save as, with the default being the one that 
causes no backward incompatibility.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: 7.0 Issues

[J. Landman Gay]

On 3/23/14, 2:23 PM, Richard Gaskin wrote:

For the long term, should plugin settings be stored separately from the
plugin itself, so that the plugin isn't modified?


Probably. But for now the most expedient solution would be a feature 
request in the QCC asking RR to preserve the file format in their plugin 
handlers. That shouldn't be too hard for them to do, and it's a good 
time to request it since v. 7.0 is in active development.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: 7.0 Issues

[Richard Gaskin]

Peter Haworth wrote:


Hi Mark,
Sure, that's fine for my custom properties.  I was meaning the cREVLoadInfo
properties that are set when you select the "Plugin Settings" item from the
Development menu Plugins item.  I'm pretty sure changing any of them
results in a save of the stack since LC has to know whether, eg, to launch
the stack on startup.


This is a tough challenge.

For v7 I've made a separate copy of my Plugins folder, and thankfully 
the team had for foresight to maintain a separate Prefs file, so that 
works for now.


For the long term, should plugin settings be stored separately from the 
plugin itself, so that the plugin isn't modified?


This raises many question. Desirable, but not simple.

--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 Follow me on Twitter:  http://twitter.com/FourthWorldSys

___
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

Re: 7.0 Issues

[J. Landman Gay]

On 3/23/14, 12:13 PM, Peter Haworth wrote:

That makes sense but the dictionary entry says:

Value:
The stackFileVersion currently has two possible values:
   - "2.4" - This stack file version is used by LiveCode 2.6.1 and earlier
   - "2.7" - This stack file version is used by versions of LiveCode after
2.6.1.


The 2.4 value is what is confusing.

That's from the dictionary entry for 5.5.4 and it doesn't even mention the
5.5 value.


That's an iffy explanation for what I meant. Version 2.6.1 was the last 
release before 2.7. What they're trying to say is that version 2.7 
changed the file format and if you save in 2.7 then version 2.6.1 won't 
open it any more. Back then, the only other file format was the 2.4 
earlier one, which all files created prior to 2.7 were using.


It's easier to think of it in the other direction: the numbers are the 
changeover version of the file format, and engines earlier than that 
number won't open files saved in later versions.


And yeah, the entry apparently hasn't been updated since 2.7 when the 
"stackFileVersion" syntax was introduced. We've had 5.5 since then and 
now 7.0. Same rules apply though.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: 7.0 Issues

[Richard Gaskin]

Mark Wieder wrote:

>> Kind of off topic but I didn't realize until recently that every
>> stack in the plugins folder is opened at startup to get the stack
>> name for display in the Plugins menu
>
> I still have hopes that someday the IDE will be open-sourced and
> we can fix these things. I'd also like to be able to specify a
> load order for plugin stacks.

Whether the community does it or RunRev does, a solution still needs to 
be found and put into the request queue.


Other than by reading the stack files, how could the display names be 
obtained?


Since Plugins are by definition focused around community efforts, IMO 
the UI and much of the spec for the APIs for managing them should be 
driven by the community.


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 Follow me on Twitter:  http://twitter.com/FourthWorldSys

___
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

Re: 7.0 Issues

[Mark Wieder]

Pete-

Sunday, March 23, 2014, 10:42:09 AM, you wrote:

> Hi Mark,
> Sure, that's fine for my custom properties.  I was meaning the cREVLoadInfo
> properties that are set when you select the "Plugin Settings" item from the
> Development menu Plugins item.  I'm pretty sure changing any of them
> results in a save of the stack since LC has to know whether, eg, to launch
> the stack on startup.

Ack! Yes, you're right. I try not to mess with the Plugin Settings
menu at all. Ever. And if I do have to open it, I do it in LC 4.6.4.

> Kind of off topic but I didn't realize until recently that every stack in
> the plugins folder is opened at startup to get the stack name for display
> in the Plugins menu

Depressing, eh? I still have hopes that someday the IDE will be
open-sourced and we can fix these things. I'd also like to be able to
specify a load order for plugin stacks.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

Re: 7.0 Issues

[Peter Haworth]

Hi Mark,
Sure, that's fine for my custom properties.  I was meaning the cREVLoadInfo
properties that are set when you select the "Plugin Settings" item from the
Development menu Plugins item.  I'm pretty sure changing any of them
results in a save of the stack since LC has to know whether, eg, to launch
the stack on startup.

Kind of off topic but I didn't realize until recently that every stack in
the plugins folder is opened at startup to get the stack name for display
in the Plugins menu

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Sun, Mar 23, 2014 at 10:07 AM, Mark Wieder wrote:

> Pete-
>
> Sunday, March 23, 2014, 9:35:06 AM, you wrote:
>
> > Off to look at the code to see if I can spot what I missed, but there is
> > one area that I have no control over.  If a user decides to change the
> > plugin settings in some way, LC stores those settings in custom
> properties
> > of the stack and, I think, immediately saves the stack.
>
> Changing custom properties shouldn't be a problem. The plugin stack is
> in memory, so no harm done. It's only when you want the changes to be
> persistent that you need to save them somewhere, and that isn't done
> automatically.
>
> --
> -Mark Wieder
>  ahsoftw...@gmail.com
>
> This communication may be unlawfully collected and stored by the National
> Security Agency (NSA) in secret. The parties to this email do not
> consent to the retrieving or storing of this communication and any
> related metadata, as well as printing, copying, re-transmitting,
> disseminating, or otherwise using it. If you believe you have received
> this communication in error, please delete it immediately.
>
>
> ___
> 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

Re: 7.0 Issues

[Peter Haworth]

It seems there was a stray "save stack" lurking in my code.  I've removed
it and will put a bug fix release out there after a little more testing to
make sure all is still preserved across launches.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Sun, Mar 23, 2014 at 9:35 AM, Peter Haworth  wrote:

> Hmmm, I was not aware that lcStackbrowser saved its state to itself.  I
> agree that's a bad idea. It did at a very early release but I had requests
> to change that behavior and, unless I missed something along the way, all
> data that needs to be preserved between launches is saved in external files.
>
> Off to look at the code to see if I can spot what I missed, but there is
> one area that I have no control over.  If a user decides to change the
> plugin settings in some way, LC stores those settings in custom properties
> of the stack and, I think, immediately saves the stack.
>
> Pete
> lcSQL Software 
> Home of lcStackBrowser  and
> SQLiteAdmin 
>
>
> On Sat, Mar 22, 2014 at 6:46 PM, Mark Wieder wrote:
>
>> Bernd-
>>
>> Saturday, March 22, 2014, 11:58:33 AM, you wrote:
>>
>> > That does affect e.g. plug-ins that save their state to themselves, as
>> > lcStackBrowser does.
>>
>> This, by the way, is a very bad idea.
>> Stacks, especially plug-in stacks, should save their state variables
>> into a preferences file and not try to modify themselves. I learned
>> this lesson the hard way some time back and always ended up shooting
>> myself in many feet. Now I only have two.
>>
>> --
>> -Mark Wieder
>>  ahsoftw...@gmail.com
>>
>> This communication may be unlawfully collected and stored by the National
>> Security Agency (NSA) in secret. The parties to this email do not
>> consent to the retrieving or storing of this communication and any
>> related metadata, as well as printing, copying, re-transmitting,
>> disseminating, or otherwise using it. If you believe you have received
>> this communication in error, please delete it immediately.
>>
>>
>> ___
>> 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

Re: 7.0 Issues

[Peter Haworth]

That makes sense but the dictionary entry says:

Value:
The stackFileVersion currently has two possible values:
  - "2.4" - This stack file version is used by LiveCode 2.6.1 and earlier
  - "2.7" - This stack file version is used by versions of LiveCode after
2.6.1.


The 2.4 value is what is confusing.

That's from the dictionary entry for 5.5.4 and it doesn't even mention the
5.5 value.


Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Sat, Mar 22, 2014 at 9:58 PM, J. Landman Gay wrote:

> On 3/22/14, 6:57 PM, Peter Haworth wrote:
>
>> I also think the descriptions of the stack formats should echo the
>> Livecode
>> versions they apply to, not some other cryptic number. How do I know what
>> versions of LC will work with 2.4 or 2.7?  I don;t recall when stack file
>> version 2.7 was introduced
>>
>
> The numbers represent the version where the file format changed. File
> format 2.4 was introduced in Rev 2.4, format 2.7 was introduced in Rev 2.7,
> etc. Each engine is backward compatible, so you can use any version of
> LC/Rev equal to or higher than the file format.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> 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

Re: 7.0 Issues

[Mark Wieder]

Pete-

Sunday, March 23, 2014, 9:35:06 AM, you wrote:

> Off to look at the code to see if I can spot what I missed, but there is
> one area that I have no control over.  If a user decides to change the
> plugin settings in some way, LC stores those settings in custom properties
> of the stack and, I think, immediately saves the stack.

Changing custom properties shouldn't be a problem. The plugin stack is
in memory, so no harm done. It's only when you want the changes to be
persistent that you need to save them somewhere, and that isn't done
automatically.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

Re: 7.0 Issues

[Peter Haworth]

Hmmm, I was not aware that lcStackbrowser saved its state to itself.  I
agree that's a bad idea. It did at a very early release but I had requests
to change that behavior and, unless I missed something along the way, all
data that needs to be preserved between launches is saved in external files.

Off to look at the code to see if I can spot what I missed, but there is
one area that I have no control over.  If a user decides to change the
plugin settings in some way, LC stores those settings in custom properties
of the stack and, I think, immediately saves the stack.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Sat, Mar 22, 2014 at 6:46 PM, Mark Wieder  wrote:

> Bernd-
>
> Saturday, March 22, 2014, 11:58:33 AM, you wrote:
>
> > That does affect e.g. plug-ins that save their state to themselves, as
> > lcStackBrowser does.
>
> This, by the way, is a very bad idea.
> Stacks, especially plug-in stacks, should save their state variables
> into a preferences file and not try to modify themselves. I learned
> this lesson the hard way some time back and always ended up shooting
> myself in many feet. Now I only have two.
>
> --
> -Mark Wieder
>  ahsoftw...@gmail.com
>
> This communication may be unlawfully collected and stored by the National
> Security Agency (NSA) in secret. The parties to this email do not
> consent to the retrieving or storing of this communication and any
> related metadata, as well as printing, copying, re-transmitting,
> disseminating, or otherwise using it. If you believe you have received
> this communication in error, please delete it immediately.
>
>
> ___
> 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

Re: 7.0 Issues

[Mark Wieder]

> Saturday, March 22, 2014, 11:58:33 AM, I wrote:

> Stacks, especially plug-in stacks, should save their state variables
> into a preferences file and not try to modify themselves.

A bit of hyperbole on my part: obviously stacks can change properties
and save themselves if they don't need to maintain compatibility with
earlier versions of LiveCode.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

Re: 7.0 Issues

[Mark Wieder]

Mats-

Sunday, March 23, 2014, 4:10:28 AM, you wrote:

> As rIDE has saved itself upon closing, I too now only have two feet.
> I will change this for rIDE 4.0. I ask for guidance and opinions here on
> what would be best practice and the pros and cons of different approaches?

I don't know about "best", but here are some techniques I've adopted
(and the changes in my behavior are a direct result of the changing
file format and the need to maintain compatibility with earlier
versions):

When I work on a plugin stack I use LC 4.6.4, as this is the last
version to use the 2.4 format natively. That way when I save a plugin
stack's changes I can be sure that the format hasn't changed. If I
didn't need to maintain compatibility back to earlier versions I could
use a later LC version, but in any event the native format of the
selected version of LiveCode is what's important.

I save a preferences file in the plugin directory and write any values
I want to remain persistent into that file. This replaces my previous
behavior of setting custom properties and saving the stack. In general
I save information into this text file in the format

property value

so that it can also be edited by any text processor if necessary.
Property names are single words, no spaces or punctuation.

I have somewhat standardized boilerplate routines that read the
preferences file on opening the stack and set plugin stack properties
accordingly. Preference file contents are written when necessary (when
one of them changes; or in the case of a preferences panel, when the
Save button is clicked rather than the Cancel button). I think GLX2
still saves all its settings on quitting, but I'm too lazy to check
right at the moment.

I no longer use the save-stack-and-revert trick to update a running
plugin stack because of the problem with maintaining version and
format compatibility.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

RE: 7.0 Issues

[Mats Wilstrand]

Mark and all,

As rIDE has saved itself upon closing, I too now only have two feet. 
I will change this for rIDE 4.0. I ask for guidance and opinions here on 
what would be best practice and the pros and cons of different approaches?

Best
Mats

> -Original Message-
> From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On
> Behalf Of Mark Wieder
> Sent: den 23 mars 2014 02:47
> To: How to use LiveCode
> Subject: Re: 7.0 Issues
> 
> Bernd-
> 
> Saturday, March 22, 2014, 11:58:33 AM, you wrote:
> 
> > That does affect e.g. plug-ins that save their state to themselves, as
> > lcStackBrowser does.
> 
> This, by the way, is a very bad idea.
> Stacks, especially plug-in stacks, should save their state variables into
a
> preferences file and not try to modify themselves. I learned this lesson
the
> hard way some time back and always ended up shooting myself in many
> feet. Now I only have two.
> 
> --
> -Mark Wieder
>  ahsoftw...@gmail.com
> 
> This communication may be unlawfully collected and stored by the National
> Security Agency (NSA) in secret. The parties to this email do not consent
to
> the retrieving or storing of this communication and any related metadata,
as
> well as printing, copying, re-transmitting, disseminating, or otherwise
using it.
> If you believe you have received this communication in error, please
delete it
> immediately.
> 
> 
> ___
> 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

Re: 7.0 Issues

[J. Landman Gay]

On 3/22/14, 6:57 PM, Peter Haworth wrote:

I also think the descriptions of the stack formats should echo the Livecode
versions they apply to, not some other cryptic number. How do I know what
versions of LC will work with 2.4 or 2.7?  I don;t recall when stack file
version 2.7 was introduced


The numbers represent the version where the file format changed. File 
format 2.4 was introduced in Rev 2.4, format 2.7 was introduced in Rev 
2.7, etc. Each engine is backward compatible, so you can use any version 
of LC/Rev equal to or higher than the file format.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: 7.0 Issues

[Mark Wieder]

Bernd-

Saturday, March 22, 2014, 11:58:33 AM, you wrote:

> That does affect e.g. plug-ins that save their state to themselves, as
> lcStackBrowser does.

This, by the way, is a very bad idea.
Stacks, especially plug-in stacks, should save their state variables
into a preferences file and not try to modify themselves. I learned
this lesson the hard way some time back and always ended up shooting
myself in many feet. Now I only have two.

-- 
-Mark Wieder
 ahsoftw...@gmail.com

This communication may be unlawfully collected and stored by the National 
Security Agency (NSA) in secret. The parties to this email do not 
consent to the retrieving or storing of this communication and any 
related metadata, as well as printing, copying, re-transmitting, 
disseminating, or otherwise using it. If you believe you have received 
this communication in error, please delete it immediately.


___
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

Re: 7.0 Issues

[Peter Haworth]

Confirmed.  Seems that the bug is that the Preference doesn't take effect
until next time you run Livecode.

I took a look at the Save As... dialog too.  It lists "Livecode Stack",
"Legacy Livecode stack (2.7)", and "Legacy Livecode Stack (2.4)" which are
the same settings as I see when running v6.x and v5.x. Shouldn't there be a
new one for v7?  If so, I'll enter a QCC report.

I also think the descriptions of the stack formats should echo the Livecode
versions they apply to, not some other cryptic number. How do I know what
versions of LC will work with 2.4 or 2.7?  I don;t recall when stack file
version 2.7 was introduced but if it was v5, it would be much clearer if
the Save As menu options read "Livecode stack (v", Livecode stack (v5-v7)", and Livecode stack (pre v5)", or
something similar.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Sat, Mar 22, 2014 at 2:25 PM, BNig  wrote:

> Peter Haworth wrote
> > Hi Bernd,
> > Which preference setting are you using?  The only one I could find is
> > titled "Preserve stack file format on stacks saved in legacy format" on
> > the
> > Files and Memory tab.  No matter how I set that, if I save a stack in LC
> > from the File menu, I can't open it in versions prior to v7 ( get "file
> is
> > not a stack file" error).
> >
> > This is with stacks with no closeStack handler.
>
> That is the setting I meant. At first I also had the impression that it
> would save to the new format regardless of the setting but then I switched
> that off, closed preferences, reopend preferences, turned "Preserve stack
> file format on stacks saved in legacy format" back on and quit Livecode
> 7.0.
> After that LC 7DP1 did follow the preference for saving from the menu or
> command-s.
>
> Kind regards
> Bernd
>
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/7-0-Issues-tp4677380p4677423.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> ___
> 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

Re: 7.0 Issues

[BNig]

Peter Haworth wrote
> Hi Bernd,
> Which preference setting are you using?  The only one I could find is
> titled "Preserve stack file format on stacks saved in legacy format" on
> the
> Files and Memory tab.  No matter how I set that, if I save a stack in LC
> from the File menu, I can't open it in versions prior to v7 ( get "file is
> not a stack file" error).
> 
> This is with stacks with no closeStack handler.

That is the setting I meant. At first I also had the impression that it
would save to the new format regardless of the setting but then I switched
that off, closed preferences, reopend preferences, turned "Preserve stack
file format on stacks saved in legacy format" back on and quit Livecode 7.0. 
After that LC 7DP1 did follow the preference for saving from the menu or
command-s.

Kind regards
Bernd




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/7-0-Issues-tp4677380p4677423.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: 7.0 Issues

[Peter Haworth]

Hi Bernd,
Which preference setting are you using?  The only one I could find is
titled "Preserve stack file format on stacks saved in legacy format" on the
Files and Memory tab.  No matter how I set that, if I save a stack in LC
from the File menu, I can't open it in versions prior to v7 ( get "file is
not a stack file" error).

This is with stacks with no closeStack handler.

Maybe I'm missing a preference setting somewhere?

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Sat, Mar 22, 2014 at 11:58 AM, BNig  wrote:

> BNig wrote
> > I noticed that plug-ins in 5.5 format save in 7.0 format when opened in
> > 7.0 and the plug-in is saved.
> > This happens in spite of the the preference to save in legacy format.
>
> Upon further inspections this seems due to the fact that if one issues a
> "save this stack" on "closeStack" it circumvents the preferences to save in
> legacy format.
> That does affect e.g. plug-ins that save their state to themselves, as
> lcStackBrowser does. And this will probably affect stacks that have their
> "destroyStack" property set to true AND do a save on closeStack.
>
> I don't know if this is a bug. But it surely makes the use of plug-ins that
> save themselves a one way thing if one wants to test 7.0 DP1 alongside of
> using older versions of Livecode.
> A workaround would be to set the stackFileVersion to 5.5. in the affected
> stacks, but that does not work for protected stacks.
>
> Kind regards
> Bernd
>
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/7-0-Issues-tp4677380p4677419.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> ___
> 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

Re: 7.0 Issues

[BNig]

BNig wrote
> I noticed that plug-ins in 5.5 format save in 7.0 format when opened in
> 7.0 and the plug-in is saved. 
> This happens in spite of the the preference to save in legacy format. 

Upon further inspections this seems due to the fact that if one issues a
"save this stack" on "closeStack" it circumvents the preferences to save in
legacy format. 
That does affect e.g. plug-ins that save their state to themselves, as
lcStackBrowser does. And this will probably affect stacks that have their
"destroyStack" property set to true AND do a save on closeStack.

I don't know if this is a bug. But it surely makes the use of plug-ins that
save themselves a one way thing if one wants to test 7.0 DP1 alongside of
using older versions of Livecode.
A workaround would be to set the stackFileVersion to 5.5. in the affected
stacks, but that does not work for protected stacks.

Kind regards
Bernd




--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/7-0-Issues-tp4677380p4677419.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: 7.0 Issues

[Dr. Hawkins]

On Fri, Mar 21, 2014 at 3:11 PM, Fraser Gordon wrote:

> If I'm not careful, we might end up with Tex re-implemented inside the
> LiveCode engine.
>

If this would let me manipulate pdf in livecode, I'd be all for it.  At the
moment, I need to have a latex installation to run the pdf tools (jar).
And all I need is to be able to reassemble/insert pages into another pdf
file.  (being able to display a page would be nice, too . . .)



-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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

Re: 7.0 Issues

[Fraser Gordon]

On 21/03/2014 21:03, Richmond wrote:
> By the way; Korean (among other writing systems) seems to have been
> overlooked: it is often written vertically: i.e. Top to Bottom, Right
> to Left.

Not overlooked so much as not really possible to retro-fit into the
current implementation of fields (unlike RTL, which has been messy
enough in getting working!). Chinese, at least, is usable in LTR and RTL
directions; I'm not sure about the other two. It would definitely be
nice to support TTB (and BTT, for symmetry) but we've too many other
things on our collective plate at the moment. There's also
boustrophedon, for those feeling a pressing need to write ancient Greek
(I suspect this would actually be easier than TTB or BTT!)

If I'm not careful, we might end up with Tex re-implemented inside the
LiveCode engine. Unfortunately, I very much doubt I could live up to
Donald Knuth!

Regards,
Fraser

___
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

Re: 7.0 Issues

[Richmond]

On 21/03/14 22:52, Fraser Gordon wrote:

On 21/03/2014 20:25, Peter Haworth wrote:

Also, the new cursorMovement and textDirection properties do not have
dictionary entries.

They are not documented because RTL is still an experimental feature and
they will almost certainly change before the final release - we don't
want anyone relying on their current behaviour just to find out things
will be different in a later DP. Well done for spotting them though -
having a bug in the bug tracker will definitely make sure we remember to
add documentation when the feature becomes more stable!

Regards,
Fraser




By the way; Korean (among other writing systems) seems to have been
overlooked: it is often written vertically: i.e. Top to Bottom, Right to 
Left.


Other significant writing systems sometimes written Top to Bottom:

Chinese [Top to Bottom, Right to Left],
Mongolian (when written in Khitan small) [Top to Bottom, and Left to Right].

If Livecode aims to be really universal it needs to accommodate these 
possibilities.


Richmond.


___
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

Re: 7.0 Issues

[Peter Haworth]

Bernd,
This all happened while using 7.0, but thanks for the heads up.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Fri, Mar 21, 2014 at 1:42 PM, BNig  wrote:

> Hi Pete,
>
> I noticed that plug-ins in 5.5 format save in 7.0 format when opened in 7.0
> and the plug-in is saved.
> This happens inspite of the the preference to save in legacy format.
>
> Might that be a problem for you?
>
> It certainly is if you try out 7.0 and use a plug-in and then use 6.x and
> the plug-in will not work
> (does not load and does not show up in the plug-in menu, which is
> understandable since 6.x does not know the file format 7.0)
>
> Kind regards
> Bernd
>
>
>
> --
> View this message in context:
> http://runtime-revolution.278305.n4.nabble.com/7-0-Issues-tp4677380p4677383.html
> Sent from the Revolution - User mailing list archive at Nabble.com.
>
> ___
> 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

Re: 7.0 Issues

[Peter Haworth]

Thanks Fraser, not a big issue, just wanted to be sure you are aware.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 


On Fri, Mar 21, 2014 at 1:52 PM, Fraser Gordon wrote:

> On 21/03/2014 20:25, Peter Haworth wrote:
> > Also, the new cursorMovement and textDirection properties do not have
> > dictionary entries.
>
> They are not documented because RTL is still an experimental feature and
> they will almost certainly change before the final release - we don't
> want anyone relying on their current behaviour just to find out things
> will be different in a later DP. Well done for spotting them though -
> having a bug in the bug tracker will definitely make sure we remember to
> add documentation when the feature becomes more stable!
>
> Regards,
> Fraser
>
>
> ___
> 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

Re: 7.0 Issues

[Fraser Gordon]

On 21/03/2014 20:42, BNig wrote:
> I noticed that plug-ins in 5.5 format save in 7.0 format when opened in 7.0
> and the plug-in is saved. 
> This happens inspite of the the preference to save in legacy format. 
That definitely looks like a bug to me - the intention was that anything
that was opened in 5.5 format (the current format) would remain in that
format when saved instead of being converted to 7.0 format.

I'm glad to see people testing 7.0; the more bug reports we receive now,
the better the engine will be when it is released. With such extensive
changes to the internals of the engine, there are always going to be a
few things we didn't get right.

Regards,
Fraser

___
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

Re: 7.0 Issues

[Fraser Gordon]

On 21/03/2014 20:25, Peter Haworth wrote:
> Also, the new cursorMovement and textDirection properties do not have
> dictionary entries.

They are not documented because RTL is still an experimental feature and
they will almost certainly change before the final release - we don't
want anyone relying on their current behaviour just to find out things
will be different in a later DP. Well done for spotting them though -
having a bug in the bug tracker will definitely make sure we remember to
add documentation when the feature becomes more stable!

Regards,
Fraser


___
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

Re: 7.0 Issues

[BNig]

Hi Pete,

I noticed that plug-ins in 5.5 format save in 7.0 format when opened in 7.0
and the plug-in is saved. 
This happens inspite of the the preference to save in legacy format. 

Might that be a problem for you?

It certainly is if you try out 7.0 and use a plug-in and then use 6.x and
the plug-in will not work 
(does not load and does not show up in the plug-in menu, which is
understandable since 6.x does not know the file format 7.0)

Kind regards
Bernd



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/7-0-Issues-tp4677380p4677383.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

7.0 Issues

[Peter Haworth]

Two issues so far, all while going through the compile stage at startup
which I assume is necessary for the new file format.

On starting up on of my plugins got an error on

put arrayDecode(it) into tVar

Got the error "visual: not a visual name" with Hint: set to "fast" on the
following:

show group "SearchProgress" with visual effect "wipe down" "fast"

After receiving these messages, I closed the stack then tried to open it
again from the Plugins menu but the stack did not load.  Closed LC and
re-opened and the stack was not in the plugins menu, even though it is
still in my plugins folder.

I put a fresh copy of the plugin into my Plugins folder and launched LC7
again.  The plugin started up, gave the visual effect error but did not
give me the arraydecode error.

Also, the new cursorMovement and textDirection properties do not have
dictionary entries.

Off to the QCC but wanted to spread the word.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
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