Nested stack properties...

[SparkOut]

You can store any type of data in a custom property - even a binary file to "embed" a video file for instance. This is extremely useful, whether you can access the data directly or not. Taking a property and copying to a variable to have a "working copy" is pretty straightforward, although not quite as convenient as being able to manipulate directly. Think of a custom property as a cupboard, and a variable as the kitchen worktop. Both are places to put things, but you have to open the cupboard and put the loaf of bread on the worktop to get the sandwich made. The rest of the loaf then goes back in the cupboard (longer term storage). The worktop gets cleaned (variables ae more ephemeral).

[jiml]

Custom properties are very handy for storing data.
But please remember they can only be stored within a file that is writable.
For example, consider you have a custom property of a stack. In the IDE you can read and write that at will.
But once you compile that stack into a standalone it is readable but no longer writable.

In the case where you want a standalone to both read and write custom properties, it is best to have those attached to substacks that are stored in writable locations, such as specialfolderpath(" documents") .

Jim Lambert

[FourthWorld]

If you need arrays, and your app doesn't necessarily benefit from attaching them to a specific object, you can read and write the arrays as files with the arrayEncode and arrayDecode functions. Super flexible, no re-thinking the differences beteeen property syntax and array syntax.

[stam]

Oops, that's a bit of a gotcha then!

So just to confirm - if am relying on changing a parameter stored in a 'custom property', this must be in a file or stack in a writeable location?

I had imagined these properties would be stored in volatile memory and not written to disk, but i guess i was wrong then?

For my purposes i guess i could move these to script and global variables and where needed read/write to file but... ugh... that's going to be a major painful re-write of my first project as i've attached everything to custom properties as it seemed so convenient :-/

EDIT: Well, just confirmed this is a major issue for me... my app works flawlessly in the IDE but as standalone every part of it fails as it relies on importing data output of a medical device which it's set to store in a custom property, as i've also done with analyses. More unexpectedly i thought i'd be clever and re-use a datagrid by changing the column count, column names and widths - which works perfectly in the IDE but epically fails in the built app -- based on the above posts, i presume this again is due to being unable to write dgProps?
Uggggghhhhhhhh...

[SparkOut]

Custom properties are convenient, and less volatile than variables, but when baked into a standalone, the startup condition is fixed. If you want to update a custom property during use of the app, no problem while it is in memory. You can open your app, read the original property value, update it and set the new value back or set a new custom property. This will be saved (in memory) for the duration.

If you want to save those custom properties for use between restarts, then the stack to which those properties are attached must be writable, or else written out to an external file. No monolithic app can amend itself on any operating system.

To preserve values between sessions, frequently the way this is done is to write out data to an external app support or preferences file. Another way often seen is to make your standalone executable a "splashstack" or "launcher" which opens the working stack from a writable location. You can then save the working stack which will retain all properties including current custom property values.

If you don't need to save data between restarts then you don't have any problem. If you do, you need to think about what you want to save, and what techniques to use, but it is not especially problematic.

[stam]

Thanks SparkOut,
Having said that my app just bums out as a standalone which i presume is due to this issue. No suggestion of failure at all in IDE, as standalone almost nothing works. Will investigate further and try to get rid of as many custom properties as possible and see what happens...

[SparkOut]

What "doesn't work"?
Chances are if it works in IDE but not as standalone then there are settings in the "inclusions" tab of the standalone builder that are missing.
If you let the standalone builder search for inclusions, it it not very reliable, especially with more recent libraries. It may well be nothing to do with custom properties. (Or might, but can't tell, although I suspect missing inclusions.)

[stam]

Yes sorry, my bad (as usual!). I forgot to include a script only stack i wrote for some lengthy processing algorithms.
Actually all works fine, please ignore my previous comment...

[FourthWorld]

Yes sorry, my bad (as usual!). I forgot to include a script only stack i wrote for some lengthy processing algorithms.
Actually all works fine, please ignore my previous comment...

Glad to hear it.

Which field of medicine if the device for? I recently shipped a LiveCode app for an optometry device.

[stam]

[Which field of medicine if the device for? I recently shipped a LiveCode app for an optometry device.

This is for cardiology/cardiac imaging - just an in-house app to process the outputs from 3D echocardiography quantification. It's relatively minor/niche, but I thought converting an existing app i wrote some time ago in XOJO would help me get up to speed with some basics in LiveCode... while also adding features I've been meaning to do for 3-4 years(!).