LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
dalkin
- Posts: 176
- Joined: Wed Jul 04, 2007 2:32 am
- Location: Blackheath, Australia
-
Contact:
Post
by dalkin » Thu Feb 11, 2021 4:56 am
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.
If we're treading on thin ice, well you might as well dance.
-
bogs
- Posts: 5435
- Joined: Sat Feb 25, 2017 10:45 pm
Post
by bogs » Thu Feb 11, 2021 11:22 am
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
- Livecode Staff Member
- Posts: 516
- Joined: Fri Feb 24, 2006 9:45 am
Post
by elanorb » Thu Feb 11, 2021 12:16 pm
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
Elanor Buchanan
Software Developer
LiveCode
-
bogs
- Posts: 5435
- Joined: Sat Feb 25, 2017 10:45 pm
Post
by bogs » Thu Feb 11, 2021 12:53 pm
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
- Posts: 176
- Joined: Wed Jul 04, 2007 2:32 am
- Location: Blackheath, Australia
-
Contact:
Post
by dalkin » Thu Feb 11, 2021 11:55 pm
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.
If we're treading on thin ice, well you might as well dance.
-
Davidv
- Posts: 77
- Joined: Sun Apr 09, 2006 1:51 am
- Location: Australia
Post
by Davidv » Fri Feb 12, 2021 8:39 am
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.