Where do you save preferences?

[Richmond]

On 19/06/12 15:50, Kee Nethery wrote:
> Wouldn't altering a file inside the application bundle invalidate the code signing required by MAS and makes it look to the OS as though some malware has altered that application?
>
> Kee Nethery
>
>> On 19/06/12 09:45, Peter Haworth wrote:
>>
>> Personally I would save any preferences from a Macintosh standalone inside
>> the application bundle:

Before anybody thinks Peter Haworth is daft, I should point out that I 
wrote about saving
preferences inside application bundles . . .  :(

Surely it doesn't matter where preferences are stored unless:

1. Where you store them mucks up how the Operating system works.

2. The standalone is subsequently unable to find the preferences file.

3. The preferences file overwrites and/or interferes with a file from 
somewhere else.

4. The OS is 100% rigid about where a preferences file MUST be stored.

It seems to me that #2 is potentially the most troublesome, especially 
if the default setting
for the Livecode engine is at a location where the end-user of the 
app/standalone is not
permitted to store data without some sort of authentication.

If . . .

----- Old Chestnut Warning -----

A standalone could save data into one of its own substacks the whole 
problem might not be
a problem at all.

----- Is It Time To Consider Playing Conkers? ----


Maybe I'm a bit stupid, but:

I do understand why RunRev won't allow substacks to be saved in 
standalones (after all, we'd
all be merrily churning out PowerPoint clones) . . .

I wonder if it would be possible to allow some sort of field in a 
substack in which non-executable
code could be stored?

i.e. either text containing a limited list of words (i.e. not all the 
command, function and so on words
in the LC lexicon) or a series of comma delimited numbers.

This would allow a standalone to store the equivalent of a text file 
containing enough information
for end-user preferences without compromising the fact that one should 
not be able to author
further stuff with a standalone.

For the sake of argument, RunRev could issue/market a specially coded 
stack that could be bound into
a standalone as a substack that contained a field that could store 
restricted data types.

>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode