This is right. I do a similar thing, but I have a command I wrote that gets all
the objects on a card, excluding groups and fields that are in a datagrid, then
loops through each one for a property I set in them indicating the array key I
want to populate the field with. This way I can load data
I don’t think you can count on the shutdown message, so you would export on
each change.
Arrays can use text for the key, so you could make things easier by using loops
and field names.
Thanks,
Brian
On Aug 15, 2018, 4:58 PM -0500, John McKenzie via use-livecode
, wrote:
>
>
> Hello again, eve
Hello again, everyone.
Jacqueline, I enjoyed the fact you shared your story of not
conforming to gender stereotypes with your childhood interests. Find it
sad that science and engineering in general was (is?) considered a boys
thing.
Feel like I want to inject my two cents worth about softw
On 8/4/18 2:27 PM, John McKenzie via use-livecode wrote:
Thank you to the additional people who welcomed me. I contrast this
with the time I asked a question on Usenet about a scripting language I
was learning and the first reply told me I was awful (true, which is
why I was asking questions) a
Putting text into a field pro-grammatically doesn't fire the openfield and
closefield handlers so yes, you'd need to add code to your button. You can
either write the code directly, or you can use send (or dispatch) and have
the field do it.. IE send "closefield" to field "whateverfield"... But
A little less busy now so I can look at my app some more. As you mat
recall I was asking about data persistence.
Thank you to the additional people who welcomed me. I contrast this
with the time I asked a question on Usenet about a scripting language I
was learning and the first reply told me
Here is one direction...
yamlFileToArray
https://github.com/trevordevore/levure/blob/master/framework/levure.livecodescript
Thanks,
Brian
On Jul 31, 2018, 3:03 PM -0500, Alex Tweedly via use-livecode
, wrote:
> On 31/07/2018 20:03, Richard Gaskin via use-livecode wrote:
> > For all of JSON's JS-
On 31/07/2018 20:03, Richard Gaskin via use-livecode wrote:
For all of JSON's JS-friendly compactness over XML, hand-writing it
can be tedious and error-prone, so YAML was invented as the answer for
those cases where human-writability is a stronger need than parsing
efficiency (all the rules ab
Ben Rubinstein wrote:
> FWIW, if your needs are super-simple, saving the values of various
> fields - and especially if those fields are not going to have
> multi-line values, you may want to check out the keywords 'combine'
> and 'split'.
> The advantage over arrayEncode is that the file is ver
Hi John, welcome to the gang.
FWIW, if your needs are super-simple, saving the values of various fields -
and especially if those fields are not going to have multi-line values, you
may want to check out the keywords 'combine' and 'split'.
Combine takes a (simple, not nested) array and combin
And don’t forget about the way mobile can dump everything at any time too. So
you would end up with mobile disk and memory as the cache for the upstream DB
server.
On Jul 31, 2018, 11:23 AM -0500, Bob Sneidar via use-livecode
, wrote:
> That's an interesting strategy. I'm gonna mull over this an
That's an interesting strategy. I'm gonna mull over this and see if I can find
an application for it. The first thing that comes to my mind is that when I am
in the field, I sometimes cannot connect to my database, because the customer
network is heavily firewalled, and my cell phone can't get a
No, the memory db is in memory, the file db is still a file. Also forgot,
you should probably quote the filename 'pathtofile.db' otherwise it gets
confused (unless you use a file with no extension.
The nice thing about this is you can have your nice persistent file db,
open a memory db, then do a
Interesting... does it load the file database into memory?
Bob S
> On Jul 30, 2018, at 08:19 , Mike Bonner via use-livecode
> wrote:
>
> Doh. Been a bit since I did it. Its-- ATTACH DATABASE pathtodb.db as dbname
___
use-livecode mailing list
use-
Doh. Been a bit since I did it. Its-- ATTACH DATABASE pathtodb.db as dbname
On Mon, Jul 30, 2018 at 8:55 AM Mike Bonner wrote:
> Sorry.. To elaborate, yes you can attach a disk based db to a memory db.
> Then you use dot notation to specify which database you're working on.
>
> So it would be a
Sorry.. To elaborate, yes you can attach a disk based db to a memory db.
Then you use dot notation to specify which database you're working on.
So it would be a regular attach-- attach pathtodatabase.db as dbname
Then any place you would specify a table name it would be dbname.tablename
On Mon,
Yes
wrote:
> Wait, you can attach a disk based database to a memory database??
>
> Bob S
>
>
> > On Jul 27, 2018, at 15:19 , Mike Bonner via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> >
> > On the subject of sqLite/memory databases and preferences/data
> persistence,
> > rather than
I know. I actually saved an arrayEncoded livecode array to file, then see if I
could parse it for the purposes of creating a searchable array handler. I had
to give up because as I sair, the format is not straightforward.
Bob S
> On Jul 27, 2018, at 15:47 , Richard Gaskin via use-livecode
>
Wait, you can attach a disk based database to a memory database??
Bob S
> On Jul 27, 2018, at 15:19 , Mike Bonner via use-livecode
> wrote:
>
> On the subject of sqLite/memory databases and preferences/data persistence,
> rather than using an array, and doing the encode/decode stuff, would it
Mike Bonner wrote:
> On the subject of sqLite/memory databases and preferences/data
> persistence, rather than using an array, and doing the encode/decode
> stuff, would it make sense to do the following..
> 1. open an empty in memory database
> 2. attach a disk based database
> 3. copy the requi
On 07/27/2018 02:58 PM, Mike Bonner via use-livecode wrote:
Your Bran. will be assimilated. (borg zombies FTW)
Yes. More brains please.
--
Mark Wieder
ahsoftw...@gmail.com
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please
Bob Sneidar wrote:
> I tried reading an "LSON" format, but it's not straight forward. It's
> easier to simply arrayDecode the LSON and work with the array.
I think there's a misunderstanding here: LSON *is* the standard LC
encoded array.
--
Richard Gaskin
Fourth World Systems
Software Des
J. Landman Gay wrote:
> On 7/27/18 2:26 PM, Richard Gaskin via use-livecode wrote:
>> if the result is empty then
>>return "Error in getTempSavedParams: "& the result for error
>> end if
>
> I believe you had a thinko: "not empty", yes?
Indeed I did - thanks.
--
Richard Gaskin
Fourth World
Use case is a major driver though. If you have no need to hand edit a
file, then LSON is an efficient and easy way to store the data. It also
has the benefit of being able to easily store binary data if needed.
On Fri, Jul 27, 2018 at 5:40 PM, Richard Gaskin via use-livecode <
use-livecode@lists
Sannyasin Brahmanathaswami wrote:
> Richard wrote " If that native form is an array, there may be no need
> to do anything more than what LC already gives us straight out of the
> box."
>
> I have been toying with this for some time, but like Alex said..
>
> "I just wish there was a human-readabl
Alex Tweedly wrote:
On 27/07/2018 20:17, Richard Gaskin via use-livecode wrote:
> Using arrays intigues me, especially if I can just keep it in RAM (It
> is a small amount of data for sure).
One great thing about LC's built-in support for arrays is that it's
built-in.
JSON has become used
On the subject of sqLite/memory databases and preferences/data persistence,
rather than using an array, and doing the encode/decode stuff, would it
make sense to do the following..
1. open an empty in memory database
2. attach a disk based database
3. copy the required table(s) from disk base to me
On 7/27/18 2:26 PM, Richard Gaskin via use-livecode wrote:
if the result is empty then
return "Error in getTempSavedParams: "& the result for error
end if
I believe you had a thinko: "not empty", yes?
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software
I tried reading an "LSON" format, but it's not straight forward. It's easier to
simply arrayDecode the LSON and work with the array. And since you can convert
the array to a memory sqLite database and back again with my handy dandy
handlers, everybody wins!
Bob S
> On Jul 27, 2018, at 12:52
Your Bran. will be assimilated. (borg zombies FTW)
On Fri, Jul 27, 2018 at 3:39 PM J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 7/27/18 12:47 PM, John McKenzie via use-livecode wrote:
> > Tom, thank you for welcoming me. Much different than some online
>
On 7/27/18 12:47 PM, John McKenzie via use-livecode wrote:
Tom, thank you for welcoming me. Much different than some online
programming groups. :-)
We love new users, it's more brains for the collective. :)
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software
Richard Gaskin
This is where serialization comes in, collecting all the disparate
pointer contents and packing them into a bytestream that can be saved or
transported, using arrayEncode:
Ha! I knew that would bring out something useful... thanks for upgrading the
handlers.
Richard
On 27/07/2018 20:17, Richard Gaskin via use-livecode wrote:
> Using arrays intigues me, especially if I can just keep it in RAM (It
> is a small amount of data for sure).
One great thing about LC's built-in support for arrays is that it's
built-in.
JSON has become used in so many other lan
Sannyasin Brahmanathaswami wrote:
> (rough draft code)
>
> Local sTempParamArray # may good to save a local,
>
> Command saveTempParams
>
>Put fld "fuelNeed" into pTempParamArray["fuelNeeded'}
>Put fld "timeToArrival" into pTempParamArray["timeToArrival""
>
John McKenzie wrote:
> Because I like word play I might make my own text file format, the
> "Extended Livecode Optimized Serialized Object Notation" format or
> ELSON. It adds just enough features to LSON to make identical to JSON.
> Being stupid and redundant it will be the hot new buzzword in t
Thanks for the extra comments everyone. Glad my thought process was
correct, databse is overkill, saving every text change is too much,
etc, etc.
As I said I will not be able to really do anything until next week.
Thanks for mentioning the closeField command guys. I will check it
out, but th
Welcome John!
You will need this, I would endorse Tom's arrayEncode.
If you have not: Learn to array code RIGHT NOW, before going further with
Livecode. I resisted array for years, and it bought me a boat load of silly
coding of text files. And 100 of lines of unnecessary code then I are
John McKenzie wrote:
> An SQLite database seems like extreme overkill but I will give it
> a try if it is needed to get the app to work.
SQLite is very feature-rich, but if you don't need the relationality
provided by a full-featured RDBMS it can be like swatting flies with a
grenade launcher.
Hi John,
> Am 27.07.2018 um 19:47 schrieb John McKenzie via use-livecode
> :
>
> Tom, thank you for welcoming me. Much different than some online
> programming groups. :-)
>
> Brian and Tom thank you for your replies about my Android data
> persistence problem. An SQLite database seems like ext
Tom, thank you for welcoming me. Much different than some online
programming groups. :-)
Brian and Tom thank you for your replies about my Android data
persistence problem. An SQLite database seems like extreme overkill but
I will give it a try if it is needed to get the app to work. Does thi
welcome john.just as a tiparrayencode is very handy for saving
whatever you needyou can always also use a sqlite database to store
data and load / refresh whenever you needit also also works as
in-memory database.
On Mon, Jul 23, 2018 at 6:21 PM, Brian Milby via use-livecode <
use-
I built a time tracking app that had the same type of persistence requirement.
I used a text file for the data store. Each time any field had a change, the
data was saved again. When loading the app it would import the current data.
Data was only cleared on request (and I would only allow that a
On Apr 19, 2012, at 1:36 PM, J. Landman Gay wrote:
> On 4/19/12 12:14 PM, Graham Samuel wrote:
>>
>> Thereafter one can update it as appropriate (at quit, or every time
>> it changes - not sure which is the best policy).
>
> I usually update on quit (shutdown) but I don't think it matters which
On 4/19/12 12:14 PM, Graham Samuel wrote:
As I suspected: but when I put my data stack into the bundle via
'Copy Files' in the Standalone Settings, it doesn't go into
Documents, does it? This copy is in effect just as read-only as the
Splash stack.
Right, the whole engine folder is read-only.
Colin, thanks
As I suspected: but when I put my data stack into the bundle via 'Copy Files'
in the Standalone Settings, it doesn't go into Documents, does it? This copy is
in effect just as read-only as the Splash stack. I guess I have to do something
like:
- check if the data stack is in the
With iOS you have to save a copy of the stack into the documents folder, and
then jump into that stack. Then changes can be saved.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage you
46 matches
Mail list logo
