Universal Import/Export Business (not James Bond Related)

[dalkin]

Can someone please point me to a resource that succinctly explains how to export text field and button data to a file then import (load) that data back into a LC standalone app?

In the standalone app settings there is a setting for the LC 'document' file icon, with Document type & Document extension options. I know that image and csv are catered for but in my case, I'm looking to create something a bit more 'proprietary' ie. a combination of the contents of text files and button choices that can only be imported and opened in the standalone.

I can't find this particular combination addressed. The dictionary sheds no light on this.

Eg. on one of my button sets I have:

Code: Select all

 set the label of button "Record1" to "Recorded" and set the backgroundColor of graphic check1 to red.

[bogs]

I'm not sure I get what you mean exactly, so this answer may be WAY off.

My take is that you have sets of buttons where the label of the button has the information you want saved to a (text | binary) file, along with a color (?), and you want it to only be readable in Lc ?

*If* that is correct, your likely talking about the read/write to/from file/binFile, and probably throwing encryption/decryption (or encode/decode) in to boot.

If it isn't correct, then I don't know unless you mean something like the Delphi "Record" command

Dr. No had nothing to do with the answer above

[elanorb]

I wonder if you might find the properties property useful. This is an array that specifies an object's properties and values.

You could get the properties of the objects you are interested in, convert the array to something you can write out to file using arrayToJSON or arrayEncode and save it to file. Then in the standalone you can read in the file, convert back to an array and set the properties of the object.

I hope that might be some help, but it might not be quite what you are trying to achieve.

Elanor

[bogs]

Funny you should mention those, Elanor, I was just playing with them yesterday

The following produces lists of "the properties" in different ways, they are in NO WAY polished examples (mostly just in the mouseUp handler) but more for testing different theories of mine.

Code: Select all

// this code just produces all the properties, whether they have value or not. Certainly I would suggest looping through the field one more time to remove empty value items...

   put "" into field 1
   # lock screen -- dramatically speeds up the time through the following.
   # lock messages -- adds speed to the above.
   put the properties of the templateButton into tVar
   put the keys of tVar into field 1
   sort field 1 ascending

   put the milliseconds into tStart
   repeat for each line x in field 1
      put x & tab & tVar[x] & cr after tList
   end repeat
   put tLIst into field 1
   
   #unlock screen -- not necessary, but I do.
   #unlock messages --same as above.
   
   answer the milliseconds -tStart

Code: Select all

// this does the same as above, but makes buttons to hold the property and it's value.
/*
...As an example of the above mention of "Lock" time differences...
   no lockScreen time = 3089 milliseconds
   lockScreen on, time = 155 milliseconds
   lock screen & lock messages = 63 milliseconds

*/

   lock screen
   lock messages
   put the milliseconds into tmpStart
   
   if the number of controls of this card <> 0 then 
      delete group 1
   end if
   new group; set the rect of it to the rect of this card; set the lockLoc of it to true; set the vScrollbar of it to true
   new field in group 1; set the topLeft of it to 5,5; set the hGrid of it to true; set the fixedLineHeight of it to true --set the textHeight of it to 15
   put the properties of templateField into tVar
   put the keys of tVar into tIndex 
   sort tIndex
   
   put the the left of field 1 into pos1
   put the right of field 1 + 5 into pos2
   put the top of field 1 - 8 into pos3
   
   repeat for each line x in tIndex
      
      if tVar[x] is not empty then
         new button x in group 1
         set the showBorder of it to false
         set the topLeft of it to (pos1,pos3)
         
         new button tVar[x] in group 1
         set the style of it to "checkbox"
         set the topLeft of it to (pos2,pos3)
         
         put pos3 + 23 into pos3
      else 
         next repeat
      end if
   end repeat
   
   unlock screen
   unlock messages
   answer (the milliseconds -tmpStart)
   

[dalkin]

No rest for the wicked, eh? Thanks to everyone who contributed to this. I'll work through this over the weekend and report back.

The more I think about it, the more I think it might be worthy of an LC dedicated lesson. After all, opening an app, then working on an output from that app, then saving that as a discrete file/document - then reopening it and re-working it at some future point seems to be an integral feature of most apps I can think of eg. MS Word, Pages, TextEdit ... others can be image editors, music DAWs etc. all require a process of create document, work on document, save document and reopen document. Think of these as being a 'child' of the app 'parent'.

This is achievable from within LC by eg. cloning a card and saving/retrieving the result but this approach stores the data within the app bundle itself, potentially leading to a huge footprint, which also runs the risk of the entire bundle being inaccessible if data corruption takes place somewhere along the line.

I can't be the first person to have raised this though but I can't find any resources addressing this, please forgive me if I'm overlooking the bleeding obvious. Old age beckons.

[Davidv]

Hi dalkin,

My interpretation is that you want to save certain settings on a file basis rather than a global basis, so they should be part of the file, which is otherwise a readable text file. I am replying on that basis.
You know how to collect the settings into textual form (e.g. as Elanor described), so it is a matter of recording these in association with the file. Once upon a time, I used this:
- Generate a decently sized (e.g. 20+ byte) [pseudo-]random string. Any starting key will do, because that is thrown away.
- Write it to the first line of your output.
- Write on subsequent lines your settings which are local to this file.
- Write the previous string -- you have an end marker you discovered on the first line.
- Write your text file.

Benefits:
- This associates your parameters with your data because they are in the one file, no chasing around other directories or losing the association.
- It is trivial yet reliable to separate your parameters from your data -- it is exceptionally unlikely your marker string will appear in your presumably readable text file (add to random string to reduce probability)
- Uncomplicated.