Saving preferences vs (or in addition to) saving data

[teacherguy]

OK, so here:

Code: Select all

 ## This will be empty if everything is OK, but will contain a hint on what might have gone wrong
  return the result
end mk_setprefs

I could do:

Code: Select all

 ## This will be empty if everything is OK, but will contain a hint on what might have gone wrong
return the result
if it is not empty then
   put it into tProblem
   answer "could not create a preferences file:" && tProblem
end if
end mk_setprefs

etc.

[Klaus]

Hi teacherguy,

this won't work:

Code: Select all

...
## This will be empty if everything is OK, but will contain a hint on what might have gone wrong
return the result
## At this point the function has been left!
## So the following IF will never be executed!
## and: IT <> the result
if it is not empty then
   put it into tProblem
   answer "could not create a preferences file:" && tProblem
end if
end mk_setprefs

BUT checking the result is already done at teh end of my "mk_collectprefs" handler!

Code: Select all

...
 ## Now we call the function that will store this to a text file
   put mk_setprefs(tAllPrefs) into tResult
   
   ## Better doublecheck!
   if tResult <> empty then
      answer "There was an error when saving the preferences!" & \
             CR & tResult
   end if
end mk_collectprefs

Best

Klaus

[teacherguy]

Thanks. I have a friend helping me test (he's on XP), and his changes were not saving (or more likely, not loading upon restarting the app). I asked where he had the app stored, and he said he is running it from the desktop. Would that be an issue in and of itself?

[mwieder]

Running from the desktop shouldn't be a problem, but where are you saving the preferences to? (or loading them from?)

[teacherguy]

Utilizing Klaus' script, they are going to:

## Everything >= Win2000
if the systemversion contains "NT" then
put specialFolderPath(26) into spfp

I think I'm going to modify the script to return the path in an answer dialogue for now so I can see where the file is ending up.

[teacherguy]

I had him track down the folder that gets created, and it was where it was supposed to be, but empty. So the prefs file did not get written, I probably have the handler in the wrong place during the quitting process, or I wasn't including it in the various quitting scenarios like clicking the x, etc. Works on mac though!

[teacherguy]

## NEW!
put the ALPHAdata of img tShortName of cd i into tAlphaData
## Step 1: convert binary data to text data:
put base64encode(tAlphaData) into tAlphaDataText

## Step 2: convert this string to ONE line:
put urlencode(tAlphaDataText) into tContent2
end if[/code]
Get the picture?

Then, in mk_collectprefs I need to add this, yes?

put i & TAB & tType & TAB & tShortName & TAB & tStyle & TAB & tContent & TAB & tContent2 & CR after tAllPrefs

[hairydalek]

Got a question about this. It works well, but I am saving two images in the file as well as data in fields. The images, which if saved as PNGs on their own weigh in around 10MB each. However, when saved through Klaus’ script, the two together add up to around 140MB! Ouch!

I was hoping to find a way to bundle the images and the folder in a way that would appear as a file to the OS (Mac, Windows etc), so I can drop the images as separate files, and use Klaus’ scripts to save the rest of the data - making a massive saving. I’ve not found a way to achieve a cross-platform file bundle yet.

[jacque]

I didn't read the whole set of threads but I believe the size increase its due to the conversion of binary data to text. If you just want to store images as binary then why not use a stack as your preference file? You can store anything as a custom property and the file will be recognized by your app on any platform. You may not even need to split the images out into a separate file if the rest of your preferences are just text bits.

[hairydalek]

Wouldn‘t saving as a stack mean a lot of duplication of the application? I’ve read a bit about tat, and I’m still not sure how that would work. As I understand it, the stack would be part of the application, you’d be saving the whole lot - so how would you handle software updates, fixing bugs, madding new functionality. This sounds like once the data is saved that it’s locked to the parent.

This isn’t about storing preferences. It’s about saving a file for people to load later and continue working on if needed. I’m thinking that the relationship between the stand alone application and the saved data is the same as, say, Word and a Word File (.doc). In this example, I‘d be writing and reading the .doc file. If the stack containing the document data can be saved as a completely separate entity, then maybe, but it doesn’t quite feel right to me - it would be a .livecode file associated with LiveCode and not my application. I need to think about updates to my application - adding new functionality down the line and being able to load saved data from previous versions. If the saved data is part of the application sick file, then surely this would mean that once saved, that data is locked to that particular application container?

So I’m leaning towards creating some kind of folder based file structure, so the images used and a file comprising a dump of the various fields and variables needed to rebuild the document is likely to be the way to go. I’m not sure, though, if I can create a file based on a bundle for Windows in the way that I can for the Mac.

[jacque]

It's easy to save a stack as a separate file, and it's how I usually do it for preferences. But you can use the technique for anything else too. If you don't want it to open with the LC IDE then give it a custom extension; LC doesn't care what the filename is as long as it's a valid stack. I often use ".dat" just because it's fairly ambiguous.

Save the stack in the user's Documents folder or application support folder. Your app can open the stack, invisibly if you want, extract any data you need, and display it. Besides easy access to text and images, you can also store arrays in custom properties or any other type of data.

Code: Select all

create stack "dataStore"
copy image 1 of this cd of stack "myApp" to cd 1 of stack "dataStore"
set the filename of stack "dataStore" to (specialFolderPath("documents") & "/myAppData.dat")
save stack "dataStore"

Or if you'd rather save the image as binary data, use:

Code: Select all

set the cImage of stack "dataStore" to the imagedata of img 1 of this cd of stack "myApp"

If you would rather save a folder, then you can do that too. Create the folder and export the images to it, then use the revZip external if you want a single file. I don't usually mess with zipping and unzipping because it's so much easier to just stuff things into a stack, but you could.

[hairydalek]

Hi,
thanks. I’ll look at the stack option as that seems to sound like more sense to me (path off least resistance). The zip file option was something I was reading up about last night, which is interesting too.