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
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
Not sure if this helps, but LiveCode 7 uses a different arrayEncoding than
previous version due to Unicode. Check the dictionary on how to use arrayEncode
in 7 to be able to decode in an earlier version.
Eric
On Feb 19, 2015, at 12:16 PM, Peter Haworth p...@lcsql.com wrote:
I've been
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
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.
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
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
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
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
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.
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
Thanks Eric. I guess I'll have to go the do route. Your bug report is
13406, I just added a comment to it.
On Thu Feb 19 2015 at 2:22:53 PM Eric Corbett e...@canelasoftware.com
wrote:
Hi Peter,
I forgot about that fact. I just checked some code in a library we use and
indeed the
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
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
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
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
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
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
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 mwie...@ahsoftware.net wrote:
Call me crazy, but I think if you set the IDE
On Sun, Mar 23, 2014 at 7:23 PM, Mark Wieder mwie...@ahsoftware.net 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
Thanks Mark, you beat me to it.
Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
On Sun, Mar 23, 2014 at 7:39 PM, Mark Wieder mwie...@ahsoftware.net wrote:
Now filed as
On Sun, Mar 23, 2014 at 6:40 PM, Mark Wieder mwie...@ahsoftware.net 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
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
Peter Haworth pete@... 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
[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
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
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
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.
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
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
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
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
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
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
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
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
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
On Sun, Mar 23, 2014 at 11:14 AM, Mark Wieder mwie...@ahsoftware.netwrote:
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
On Sun, Mar 23, 2014 at 12:10 PM, Richard Gaskin ambassa...@fourthworld.com
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
On Sun, Mar 23, 2014 at 12:22 PM, J. Landman Gay
jac...@hyperactivesw.comwrote:
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
On Sun, Mar 23, 2014 at 12:23 PM, Richard Gaskin ambassa...@fourthworld.com
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
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
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 http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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
Thanks Fraser, not a big issue, just wanted to be sure you are aware.
Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
On Fri, Mar 21, 2014 at 1:52 PM, Fraser Gordon
Bernd,
This all happened while using 7.0, but thanks for the heads up.
Pete
lcSQL Software http://www.lcsql.com
Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and
SQLiteAdmin http://www.lcsql.com/sqliteadmin.html
On Fri, Mar 21, 2014 at 1:42 PM, BNig bernd.niggem...@uni-wh.de
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
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
On Fri, Mar 21, 2014 at 3:11 PM, Fraser Gordon fraser.gor...@runrev.comwrote:
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
64 matches
Mail list logo
