Where do you save preferences?
richmondmathewson at gmail.com
Tue Jun 19 09:04:09 EDT 2012
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
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:
More information about the Use-livecode