LiveCode Forums.

I hope someone can explain this at a level I can understand (use small words and simple concepts please ) since I am not even sure I will communicate the question properly. What I am trying to find out is where a stack (? the thing with .livecode extension ) loaded in the IDE is running from? Is it running solely in memory? in a tmp folder? where the stack was loaded from? The question refers to using external files, however when running the program in the IDE I don't seem to be accessing the files in the folder with the stack.

If the question needs clarification, please feel free to say so and I'll try asking it differently. I just have had no luck finding out on my own, and it doesn't seem to work like other environments I am used to.

I think someone also mentioned (in a side conversation) that the file formats change between Lc revisions, if this is correct, is the safest way to work among multiple versions of Lc to 'save as' to the legacy format as the lowest common denominator? If so, are there any pitfalls I should be aware of? If I use 'save as' to get to the legacy format, will subsequently just saving it continue to save it in legacy format, or do you have to use 'save as' every time?

Also a bonus round question.
. I started writing a program, got fairly far along and didn't want to mess up what I had so far.
.. I opened a new stack and saved it as a testingProgram stack to experiment with code.
... I copied all the controls from the original program stacks card and pasted them into the new 'testing' stacks card, both cards are named the same.
.... I now find that code that worked in the original stack does not work any longer in the 'testing' stack.

The code itself is pretty generic, so I am assuming there is something going wrong in the copying of the controls or code itself process, does anyone know how I could check to find out what or any suggestions for things you might have come across that are similar in nature?

Answers to any or all of these questions will not result in a reward, but you will have my gratitude

Hi bogs,

not sure I really understand your problem, but when you open a stack, Livecode will load it
completely into memory including eventual substacks and run it from there.

When saving a stack in an earlier stack file format, the only problem may be that new features,
the ones not available in the earlier format, will be lost. Like widget if you save a stack created
in LC >= 8 in <= 7 format.

In the LC preferences "Files & Memory" there is a checkbox "Preserve stack file version on stacks saved in legacy format".
That means if you open a stack save in LC 7 in LC 8 then each "Save" will preserve the 7 file format.

Hope that helps.


Best

Klaus

Heya Klaus!

I knew I probably explained it poorly the first time, hopefully a picture really *is* worth a 1000 words, I'll try again. So, I open this project (the documentation appears to refer to stacks as both the file and the window in the user manual, so for clarity I will just refer to the file as the project for this discussion), and when testing it from inside the IDE, it appears to be getting the previously recorded times (times.text) from somewhere other than the file in the folder with it.

When run as a standalone, it works properly, reading in the file. For brevity in the code, I used the relative path ("./times.text"), however in the IDE there seems to be no difference when using the relative, built (put folder into tPath/etc), or direct to file path, the IDE seems intent on using this other file, so I am trying to figure out where this is and how to change it to use the ("local to the project") copy of the file?

Other environments I program in either debug directly in the folder your project resides in, or in a temporarily created debugging folder in that folder. In either case, you can usually use something like : but I haven't come across anything I recognize to do this in Lc (although I am sure such exists).

I know the file times.text isn't coming from memory in the IDE, since it does have information that wouldn't survive from session to session. Other than that, though, I am stumped
<*Edit > I think I figured this part out, apparently it is creating the file in my home directory (Linux). How do I change this to use the local file in the project folder still remains a question though. </*Edit >

Legacy format
Just checking to make sure I have this right, I did check that box in prefs that you mentioned, and I read it pretty much as you explained it, that if you save in lets say Lc 6.0.1, then opened it in Lc 9.x.x (which has the same box checked), when you saved it it should be saved in the 6.0.1 file format/version.

The reason I was asking if you have to use "save as" each time is that a lot of the time Lc opens a dialog saying "This is not a stack file" (or something to that effect). Am I confused? You betcha

The answers did help though, I hope the picture above does as well

Hi bogs,

bogs wrote:Heya Klaus!

I knew I probably explained it poorly the first time, hopefully a picture really *is* worth a 1000 words, I'll try again.

OK, let me see, hope I get it right:

Where is this coming from?

At some point you are setting "the htmltext" of this field to the content of a file, see below

What the file actually shows...

And at another point you are obviously writing the htmltext of that (or another file) back to that file.

Please post some scripts you are using, otherwise I cannot tell you anything about the "origin" of the files in question.

bogs wrote:So, I open this project (the documentation appears to refer to stacks as both the file and the window in the user manual, so for clarity I will just refer to the file as the project for this discussion), and when testing it from inside the IDE, it appears to be getting the previously recorded times (times.text) from somewhere other than the file in the folder with it.

"window" is the visual representation of the "file" on disk.
But see above, I need to see your scripts to get an idea about what might happen here.

bogs wrote:Other environments I program in either debug directly in the folder your project resides in, or in a temporarily created debugging folder in that folder. In either case, you can usually use something like :

Code: Select all

#if debug mode then 
....use path "xyz"
else // not in debug mode
....use path "uvw"
end if

but I haven't come across anything I recognize to do this in Lc (although I am sure such exists).

Not sure what "debug mode" might be in other dev environments, but in LC you can differ "the environment"! Maybe that is what you mean.

bogs wrote:I know the file times.text isn't coming from memory in the IDE, since it does have information that wouldn't survive from session to session. Other than that, though, I am stumped
<*Edit > I think I figured this part out, apparently it is creating the file in my home directory (Linux). How do I change this to use the local file in the project folder still remains a question though. </*Edit >

Show me your script/writing routines.

bogs wrote:Legacy format
Just checking to make sure I have this right, I did check that box in prefs that you mentioned, and I read it pretty much as you explained it, that if you save in lets say Lc 6.0.1, then opened it in Lc 9.x.x (which has the same box checked), when you saved it it should be saved in the 6.0.1 file format/version.

The reason I was asking if you have to use "save as" each time is that a lot of the time Lc opens a dialog saying "This is not a stack file" (or something to that effect). Am I confused? You betcha

I never used this "feature", so maybe it is just not working as advertised?
At least it sounds like that.


Best

Klaus

Environment / debug mode, Klaus, you nailed this one exactly my friend, and have my undying thanks! I knew there had to be something similar in Lc, but didn't even know how to ask the question and you still nailed it. Now for the other parts, I feel I may be am accidentally cryptic, even with the picture.

You surmised correctly that the field (Where is this coming from) is showing the text from the file using the htmlText property, and that the file is written out using that same property, but that isn't the problem with the field or the file, that is the way it was intended to work.

If you look at the picture again, a little closer, notice the date in the field, vs. the date in the file. The date in the field is 5/1/17, the date in the file is 5/4/17. When I edited that post, I finally figured out why the field (when the program is open in the IDE) isn't reflecting that file in the picture, which is located where the projects files are.

It is because when running the program from within the IDE, it is creating that file every time in my home folder (on Linux, maybe different in other Oses). I am trying to figure out why this happens (I think this is where your 'environment' example may work for me).

The code for reading the file in is: I normally don't hard-code in paths, since I have no idea where the end user may wind up putting a program, however in trying to make sure I was using the files available in the project folder, I *did* actually try several variations of the 'URL "file:xxxx" line, the last being the complete path to the times.text file the program needed from the root directory, so I am not really sure why it insists on creating / opening the file from the home directory, the standalone version works with the file in its folder correctly using any form of the url "file:..." formats.

This is why I was wondering how and where the IDE was running the file from, obviously it is not pulling the file from where the project is opening if you see what I mean Now, if the 'environment' thingie works out, maybe I have the answer.

Any ideas on the bonus round question from the first post ? And thank you again for pointing me in what I'm sure will be the right direction =^]

*Edit -
Klaus, that was indeed the right direction, thank you soooooooo much !

Hi Bogs,

glad I could help to figure out most of your misteries!

Hint:
If you do not define a pathname, then the file will be written into the current defaultfolder, whereever that may be!
But when creating a standalone this will be "Programm Files x86'" on Windows and "Applications" on a Mac, if installed correctly,
and only users with Admin rights have write permissions here! No idea about Linux, but may be similar.

So better use -> specialfolderpath("documents")
where we have definitively write permissions!

I may be able to answer your "bonus" questions, but therefore I will need to take a look at the stacks.
If you like you can send me the stacks and I will take a look.
Send them to: klaus AT major-k.de


Best

Klaus

Just to add a bit to Klaus' comments, when LC launches it sets the default folder to the location of the LC app. It seems you've installed LC in home so that's where LC looks for all file operations when no paths are specified. You can change the folder's location by setting the defaultfolder (synonyms: folder, directory) to another location. After that, file operations will be directed there.

Fully qualified paths will always be respected regardless of the defaultfolder.

Legacy format: A stack saved in legacy format will open in a later version. A stack saved in a newer format will not open in a LC version that supports an older format. So, a LC 6 stack will open in LC 9, but a LC 9 stack will not open in 6. The latter is when you will get the message about the file not being a stack.

There is a checkbox in preferences that retains legacy format when saving. If that is turned on the format will be preserved. If it's not, you'll have to save-as each time.

Jacque, thank you very much for the explanation on the defaultFolder, it explains a lot and the dictionary references on it even more.

Now to make sure I understand it correctly, I'm going to bounce some things and see what sticks.

Klaus's 'environment' example works much like the if/then debug statements I am used to in other languages, testing that out locally showed me that

.1.) If I use the following relative path then in the IDE it will reference (in my case) the home folder, but in the compiled application it will reference the same folder the app is running from.

.2.) if I change the above to include ./ (underlined) :
[set the HTMLText of field "txtRecordedTimes" of card "Report" of stack "Report" to URL "file:./times.text"]
this changes the relative path and the IDE should pull from there as well since that is where the project stack file was loaded from (?)
*Edit - answered my own question, no that does not cause it to use the files in the folder the stack file was opened from, it does appear to be just as valid in the standalone app as the format in 1.) though.

.3.) I can also make the projects default folder change by setting the property in code ala the dictionary entry (although I wasn't able to get that to work blatantly copying the code from the dictionary, or from the notes below the entry).

This makes me ask another question (which I think I already have the answer too), does the standalone app setting for the default build folder have any impact on this? I suspect this only relates to where to build the finished app, and not at all to where the IDE is running it or pulling files from. Legacy -
All versions of Lc that I have currently installed have the preference set like so : Now, if I start and save a project in say, Lc 6.x, then later open it and save it in Lc 9, then later need to open it in the earlier version, that should work without issues?

Or would I need to use 'Save As' in Lc 6.x (initial save) to have that work ? And would I then need to use 'Save As' every time after in other versions to avoid corrupting the files?

I think whats causing the confusion for me is the wording "saved in legacy format", I guess I'm not sure just saving it in vers. 6.x saves it in legacy format or not. I am probably over-thinking this and apologize for the repetition.
*Edit 2 - I think I answered my own question again, or at least part of it. I hit 'Save As', and there are 3 options, [Livecode Stack], [Legacy Livecode Stack (2.7)], [Legacy Livecode Stack (2.4)]. I am guessing that if I choose one of the legacy modes and save it, then any time I save in any other versions that support it, it will save it in legacy format without needing to hit 'Save As' each time. That sound right?

Thank you again for taking the time to answer what I am sure sound like dumb questions

Humorous note: Yahoo bot came to visit us today

Relative paths will be different depending on the OS. I think you said you were on Linux, so in that case a ./path will work. But if you plan to distribute to Mac OS X or mobile, those relative paths will fail. To get around that, LC provides "specialFolderPath" to accomodate. See below.

You're right that the preference setting for the default build folder only applies to the location where the standalone will be saved. It doesn't affect any other files. Some people like to build on the desktop, others want the standalone to go into their project folder. This is where you'd specify.

File formats have changed several times over the years. As new features are added, the file format was updated to accomodate the changes. They are not backward compatible. You can open any stack saved in legacy format in a version of LC that is newer, but once saved, you can't open it again in an older version. If you save in LC 6 and have preferences set to preserve legacy formats, then you can re-open the file in LC 6, 7, 8, or 9. But if you save in LC 7 format, you will not be able to open it again in LC 6. Unless you intentionally choose to save the stack in a newer format, you should not need to use "save as" if preferences are set to preserve the legacy format. You will of course lose any features that the older version didn't have if you open the stack in a legacy version of LC.

About relative file paths: LC provides special folder paths for a few common locations so that you don't need to figure out actual paths. The most useful are specialFolderPath("engine"), specialFolderPath("resources"), and specialFolderPath("preferences"). In your example you would want to use specialFolderPath("resources") which is flexible enough to accomodate both development work and standalones, provided the working folder contains both the mainstack you are developing and all the resource files it uses. This is pretty much what you're describing already as your working environment. In development, specialFolderPath("resources") points to the folder containing the mainstack. In a standalone, it points to the equivalent which varies considerably by OS. But you don't need to worry about the variations because LC knows where the files are.

To create a path to a text file residing in the same folder as the mainstack, use: specialFolderPath("resources") & "/times.txt"

Jacque, you have the patience of a saint, and the explanation about 'legacy' made it completely understandable to me now.

I had come across 'specialFolderPath' in looking for answers, it just hadn't seemed to fit what I needed because I had only seen it referencing folders like Klaus mentioned, the documents folder, preferences, desktop, etc. Not one reference I had come across mentioned 'resources' (!), I think my search-fu may be beyond repair

You have indeed nailed my working habits, I keep my projects (and their files) dementedly segregated, and sometimes move stack files to other locations as well where I need to pull different resource files (same names). At that point, the code needs to be able to follow the wanderings of the file itself, thank you for pointing out what is probably the easiest way to do just that for me

Edit - specialFolderPath("resources") apparently was added after 6.6 and will not work below 6.7.x (returns nothing), but still good to know going forward!

Not one reference I had come across mentioned 'resources' (!), I think my search-fu may be beyond repair

It isn't you, the dictionary is just behind the times.

Like I said before, you are far too kind, it really is me after all who is 'behind the times'. You know how much I like the older setups, after all

It turns out that later revisions of the dictionary actually do reference most of these things, I just don't spend enough time in those later versions. The User guide now, THERE is a document that for many revisions was 'behind the times' although as I mentioned to Richard, it did get much better in 8 & 9.

Your tips though lead me to other ways to get the path back to the file folder, just not the easy peasy way of the later versions