Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

Storing Application Settings (Real Studio network user group Mailinglist archive)

Back to the thread list
Previous thread: List of Apple processes?
Next thread: color from Hex string


Re: RB Company.   -   Rubber Chicken Software Co.
  Storing Application Settings   -   Jason Glazer
   Re: Storing Application Settings   -   Arnaud Nicolet
    Re: Storing Application Settings   -   Jan-Ivar Mellingen
    Re: [OT] Which language says "skrev"? (was: Storing Application Settings)   -   Metsis
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Arnaud Nicolet
    Re: Storing Application Settings   -   Jan-Ivar Mellingen
   Re: Storing Application Settings   -   Arnaud Nicolet
    Re: Storing Application Settings   -   Bart Silverstrim
     Re: Storing Application Settings   -   Eduardo Gutierrez de Oliveira
    Re: Storing Application Settings   -   Jan-Ivar Mellingen
   Re: Storing Application Settings   -   Jan-Ivar Mellingen
   Re: Storing Application Settings   -   Norman Palardy
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Tim Jones
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Tim Jones
   Re: Storing Application Settings   -   Norman Palardy
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Joe Huber
   Re: Storing Application Settings   -   Tim Jones
   Re: Storing Application Settings   -   Tim Jones
   Re: Storing Application Settings   -   Joe Huber
    Re: Storing Application Settings   -   Bart Silverstrim
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Joe Huber
   Re: Storing Application Settings   -   Joe Huber
   Re: Storing Application Settings   -   Tim Jones
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Tim Jones
   Re: Storing Application Settings   -   Tim Jones
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   fargo rpgportland.com
   Re: Storing Application Settings   -   fargo rpgportland.com
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Tim Jones
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Tim Jones
   Re: Storing Application Settings   -   Roger Clary
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   fargo rpgportland.com
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Carlos M
   Re: Storing Application Settings   -   Carlos M
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Cameron McCormick
   Re: Storing Application Settings   -   Cameron McCormick
   Re: Storing Application Settings   -   Carlos M
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Storing Application Settings   -   Carlos M
   Re: Storing Application Settings   -   Carlos M
    Re: Storing Application Settings   -   Jan-Ivar Mellingen
   Re: Storing Application Settings   -   Arnaud Nicolet
   Re: Text versus Binary - was Re: Storing Application Settings   -   Arnaud Nicolet

Storing Application Settings
Date: 04.08.09 20:25 (Tue, 04 Aug 2009 14:25:03 -0500)
From: Jason Glazer
Sorry for such a simple question. I'm just getting started
using REALbasic after years of using VB.

What is the easiest way to store information about
application settings between times the application is used
that will work on all platforms?

I want to store some information about a list of files and
some user options. For Windows, I would use the registry but
I would like, if possible, a single way to store such
settings using REALbasic.

Jason

Re: Storing Application Settings
Date: 10.08.09 19:04 (Mon, 10 Aug 2009 20:04:32 +0200)
From: Arnaud Nicolet
Le 10 août 09 à 16:05, Jan-Ivar Mellingen a écrit:

> Well, as I see it you will always have to rely on somebody else to do
> the low-level work.

I find it more reliable, in fact.

> You have no more or less control writing to a text file than to a
> binary
> file. In the end a text file is no more than a binary file in a
> defined
> format ;-)

I always write in binary files, since I can write things as I want. I
agree: a text file should be what it means (some text that the user
should read if it's what he wants).

> In my opinion it is more likely that I myself make a bug developing my
> own code, than the possibility of a fault in a well tested library
> like
> the text-file or database plugins.

That's true.

> Anyway, my problem replacing VB's Get/SetSetting was solved this way.
> Cross-platform, no more messing with the Windows Registry, same
> logic on
> all platforms. Life is easy.

I have the impression that most guy who speaks about databases are
coming from windows... Do you have the same feeling?

> If you don't like databases, of course a text file with some id/value
> pairs or a xml structure will work just as nicely. I considered that,
> but for my purpose the use of the database file relieved me of
> having to
> parse the contents myself, simplifiying my code. In addition I can now
> easily encrypt the settings, which allows me to store even top-secret
> passwords and be pretty sure nobody can get at them. Before I had to
> encrypt them before storing, and my biggest concern then was the
> encryption libraries in use...

I think someone who learnt with databases will always find a way to
do <everything> with them and someone who learnt without them will
also be able to do <everything> without them.

> /Jan-Ivar
>
> Arnaud Nicolet skrev: <something>

May I ask you which languages says "skrev"? (always curious)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 11.08.09 13:47 (Tue, 11 Aug 2009 14:47:35 +0200)
From: Jan-Ivar Mellingen


Arnaud Nicolet skrev:
> I have the impression that most guy who speaks about databases are
> coming from windows... Do you have the same feeling?
Speaking for myself, I have been developing software for more than 40
years, but not always on Windows. Windows was invented after my first
commercial Alarm Receiving Centre database application: coded in BBC
Basic, running on the BBC computer with plenty of RAM (64KB) and huge
disks (2x400KB floppy).
Later I ported to DOS with Btrieve database (then Novell, now it is
called Pervasive SQL). I also had a short sidetrack on CP/M.
After some years coding in Modula-2 for DOS/Windows I was planning to
port to OS/2. Actually the plan was to use Visual Basic to make
cross-platform Windows / OS/2 applications. After I was finished porting
my code to VB, Microsoft dropped OS/2 support in VB, then OS/2 died...
This first application is still being developed in accordance with
customer needs and technological change. Most of the present code is
still in VB5 (Windows only), and the database is now PostgreSQL (on
Linux or Windows). The data volume has grown in theese 40+ years from
200KB to 200GB...
These days we are trying to get rid of the extremely troublesome and
instable OS called Windows and are aiming at Linux, replacing VB with RB
but keeping the PostgreSQL database (the best there is, in my opinion).
So far it looks good, everyting I have developed on Windows also runs on
Linux without any work on my part. Just compile and run!
> I think someone who learnt with databases will always find a way to do
> <everything> with them and someone who learnt without them will also
> be able to do <everything> without them.
In the 40+ years I have been coding I have used first .ini files and
later the Windows Registry for keeping settings etc. Lately I have gone
back to .ini files as it gives me more control and easier support. The
Registry is not well suited for my purpose, certainly if you have to
guide the user in order to change some obscure settings. In the process
of moving to a cross-platform environment I discovered the SQLite (RB
database) which simplified things a lot. Now we use a free SQLite
browser to change the settings, if necessary. Easier than using a text
editor on a text file...
So, I am not used to do 'everyting' with a database. Large databases are
are for managing huge amounts of data!
- But the local, tiny, single-file database has its benefits. I could
certainly find more uses for it...

/Jan-Ivar

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 10.08.09 18:04 (Mon, 10 Aug 2009 19:04:15 +0200)
From: Arnaud Nicolet
Le 10 août 09 à 13:49, Bart Silverstrim a écrit:

> Arnaud Nicolet wrote:
>> Le 10 août 09 à 12:01, Jan-Ivar Mellingen a écrit:
>>> Hi.
>>>
>>> This and related questions has been discussed on this forum before.
>>> Following the discussions I was made aware of some pitfalls I had
>>> not
>>> thought of, and ended up with a very simple solution which suited my
>>> requrements.
>>> I am using the built-in RB database for my settings, just
>>> containing a
>>> simple table. It allows me to easy port my old VB5 code, and at
>>> the same
>>> time avoid a lot of platform problems.
>> The last week, a very well-known forum (at least where I live) had
>> a database failure and every user information (from 10 years ago)
>> have been lost. Everyone had to subscribe again.
>> Since then, I have a real explanation as to why I hate databases...
>
> I haven't been a big fan of databases, but should this not be a
> reason to love proper backups??

Indeed, at any case, you end up with files and any file can be lost.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 10.08.09 12:19 (Mon, 10 Aug 2009 13:19:09 +0200)
From: Arnaud Nicolet
Le 10 août 09 à 13:14, Arnaud Nicolet a écrit:

> Le 10 août 09 à 13:06, Jan-Ivar Mellingen a écrit:
>
>> Ok - just forget it is a database, just think of the file as a binary
>> file with a really simple interface ;-)
>
> Well, it's a file for which you haven't any control on how data are
> stored. If you have arbitrary data to write, I don't see the point
> of using something made for "arranging" data (like a database).
>
> It's like using an AppleScript to eject a disk (by asking the
> Finder), while you could do it using declares and ask directly the
> OS (what if the Finder isn't running, for instance?). I don't think
> it's good to rely on external components (the more there are
> components to make something, the more something can break).

Sorry, I have to admit that others may have other opinions (still I
don't understand these opinions).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 10.08.09 12:14 (Mon, 10 Aug 2009 13:14:00 +0200)
From: Arnaud Nicolet

Le 10 août 09 à 13:06, Jan-Ivar Mellingen a écrit:

> Ok - just forget it is a database, just think of the file as a binary
> file with a really simple interface ;-)

Well, it's a file for which you haven't any control on how data are
stored. If you have arbitrary data to write, I don't see the point of
using something made for "arranging" data (like a database).

It's like using an AppleScript to eject a disk (by asking the
Finder), while you could do it using declares and ask directly the OS
(what if the Finder isn't running, for instance?). I don't think it's
good to rely on external components (the more there are components to
make something, the more something can break).

> The single-file SQLite database should really not be compared to
> the large and complex databases driving web-sites...

Well, it's true I can't compare.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 10.08.09 15:05 (Mon, 10 Aug 2009 16:05:05 +0200)
From: Jan-Ivar Mellingen
Well, as I see it you will always have to rely on somebody else to do
the low-level work.
You have no more or less control writing to a text file than to a binary
file. In the end a text file is no more than a binary file in a defined
format ;-)

In my opinion it is more likely that I myself make a bug developing my
own code, than the possibility of a fault in a well tested library like
the text-file or database plugins.
Anyway, my problem replacing VB's Get/SetSetting was solved this way.
Cross-platform, no more messing with the Windows Registry, same logic on
all platforms. Life is easy.

If you don't like databases, of course a text file with some id/value
pairs or a xml structure will work just as nicely. I considered that,
but for my purpose the use of the database file relieved me of having to
parse the contents myself, simplifiying my code. In addition I can now
easily encrypt the settings, which allows me to store even top-secret
passwords and be pretty sure nobody can get at them. Before I had to
encrypt them before storing, and my biggest concern then was the
encryption libraries in use...

/Jan-Ivar

Arnaud Nicolet skrev:
>
> Le 10 août 09 à 13:06, Jan-Ivar Mellingen a écrit:
>
>> Ok - just forget it is a database, just think of the file as a binary
>> file with a really simple interface ;-)
>
> Well, it's a file for which you haven't any control on how data are
> stored. If you have arbitrary data to write, I don't see the point of
> using something made for "arranging" data (like a database).
>
> It's like using an AppleScript to eject a disk (by asking the Finder),
> while you could do it using declares and ask directly the OS (what if
> the Finder isn't running, for instance?). I don't think it's good to
> rely on external components (the more there are components to make
> something, the more something can break).
>
>> The single-file SQLite database should really not be compared to the
>> large and complex databases driving web-sites...
>
> Well, it's true I can't compare.
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 10.08.09 11:52 (Mon, 10 Aug 2009 12:52:15 +0200)
From: Arnaud Nicolet
Le 10 août 09 à 12:01, Jan-Ivar Mellingen a écrit:

> Hi.
>
> This and related questions has been discussed on this forum before.
> Following the discussions I was made aware of some pitfalls I had not
> thought of, and ended up with a very simple solution which suited my
> requrements.
> I am using the built-in RB database for my settings, just containing a
> simple table. It allows me to easy port my old VB5 code, and at the
> same
> time avoid a lot of platform problems.

The last week, a very well-known forum (at least where I live) had a
database failure and every user information (from 10 years ago) have
been lost. Everyone had to subscribe again.

Since then, I have a real explanation as to why I hate databases...
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 10.08.09 12:49 (Mon, 10 Aug 2009 07:49:10 -0400)
From: Bart Silverstrim
Arnaud Nicolet wrote:
> Le 10 août 09 à 12:01, Jan-Ivar Mellingen a écrit:
>
>> Hi.
>>
>> This and related questions has been discussed on this forum before.
>> Following the discussions I was made aware of some pitfalls I had not
>> thought of, and ended up with a very simple solution which suited my
>> requrements.
>> I am using the built-in RB database for my settings, just containing a
>> simple table. It allows me to easy port my old VB5 code, and at the same
>> time avoid a lot of platform problems.
>
> The last week, a very well-known forum (at least where I live) had a
> database failure and every user information (from 10 years ago) have
> been lost. Everyone had to subscribe again.
>
> Since then, I have a real explanation as to why I hate databases...

I haven't been a big fan of databases, but should this not be a reason
to love proper backups??

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 10.08.09 13:49 (Mon, 10 Aug 2009 14:49:47 +0200)
From: Eduardo Gutierrez de Oliveira
On 10/08/2009, at 13:49, Bart Silverstrim <<email address removed>>
wrote:

> Arnaud Nicolet wrote:
>> Le 10 août 09 à 12:01, Jan-Ivar Mellingen a écrit:
>>> Hi.
>>>
>>> This and related questions has been discussed on this forum before.
>>> Following the discussions I was made aware of some pitfalls I had
>>> not
>>> thought of, and ended up with a very simple solution which suited my
>>> requrements.
>>> I am using the built-in RB database for my settings, just
>>> containing a
>>> simple table. It allows me to easy port my old VB5 code, and at
>>> the same
>>> time avoid a lot of platform problems.
>> The last week, a very well-known forum (at least where I live) had
>> a database failure and every user information (from 10 years ago)
>> have been lost. Everyone had to subscribe again.
>> Since then, I have a real explanation as to why I hate databases...
>
> I haven't been a big fan of databases, but should this not be a
> reason to love proper backups??

There, there. I think the attention here is in the wrong problem.

Re: Storing Application Settings
Date: 10.08.09 12:06 (Mon, 10 Aug 2009 13:06:42 +0200)
From: Jan-Ivar Mellingen
Ok - just forget it is a database, just think of the file as a binary
file with a really simple interface ;-)
The single-file SQLite database should really not be compared to the
large and complex databases driving web-sites...

/Jan-Ivar

Arnaud Nicolet skrev:
> Le 10 août 09 à 12:01, Jan-Ivar Mellingen a écrit:
>
>> Hi.
>>
>> This and related questions has been discussed on this forum before.
>> Following the discussions I was made aware of some pitfalls I had not
>> thought of, and ended up with a very simple solution which suited my
>> requrements.
>> I am using the built-in RB database for my settings, just containing a
>> simple table. It allows me to easy port my old VB5 code, and at the same
>> time avoid a lot of platform problems.
>
> The last week, a very well-known forum (at least where I live) had a
> database failure and every user information (from 10 years ago) have
> been lost. Everyone had to subscribe again.
>
> Since then, I have a real explanation as to why I hate databases...
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 10.08.09 11:01 (Mon, 10 Aug 2009 12:01:19 +0200)
From: Jan-Ivar Mellingen
Hi.

This and related questions has been discussed on this forum before.
Following the discussions I was made aware of some pitfalls I had not
thought of, and ended up with a very simple solution which suited my
requrements.
I am using the built-in RB database for my settings, just containing a
simple table. It allows me to easy port my old VB5 code, and at the same
time avoid a lot of platform problems.

The code is cross-platform and the database file is portable across all
platforms (I can copy the settings file from a Windows machine to a
Linux machine and it all works).
The database file is just a SQLite database, so it may be also opened
with a suitable library in any other language (I am using a SQLite DLL
in VB5 if I nedd to share settings between VB and RB applications).
The settings may even be strongly encrypted (AES256) by just setting the
db.EncryptionKey property.
I have placed the database file in a folder with full user access,
avoiding any permission problems. A nice side-effect is that the
settings are also copied when the user (hopefully) backs up his
documents (home) folder.
Other folders may be more suitable for settings common to several users
or several applications.

Here are some snippets from my code to get you started.
Just call OpenSettingsDB and use GetSetting / SaveSetting to administer
the settings.

Function DataFolderPath() As String
Dim f as FolderItem

If Not (TargetLinux) then
f=SpecialFolder.Documents.Child(DataFolderName)
Else
f=SpecialFolder.UserHome.Child(DataFolderName)
End if

if not f.Exists then
f.createasfolder
if f.LastErrorCode > 0 then
LogError "Could not create " + f.AbsolutePath + ", error code: " +
str(f.LastErrorCode)
Return ""
end if
End If

Return f.AbsolutePath

End Function

Function OpenSettingsDB() As Boolean

SettingsDB = New REALSQLdatabase

SettingsDB.databaseFile = GetFolderItem(DataFolderPath() +
"SettingsDBFilename")
// SettingsDB.EncryptionKey = "SettingsDBKey"

// try to connect to the database
If SettingsDB.databaseFile.Exists = True then
// The database file already exists, connect.
if SettingsDB.Connect() = False then
// there was an error connecting to the database
LogError "Open Database Error: " + Str(SettingsDB.ErrorCode) +
EndOfLine + EndOfLine + SettingsDB.ErrorMessage
Return false
End if
Else
// The database file does not exist, create a new one.
if SettingsDB.CreateDatabaseFile() = false then
LogError "Create Database Error: " + Str(SettingsDB.ErrorCode) +
EndOfLine + EndOfLine +SettingsDB.ErrorMessage
return false
end If
End if
// Create the tables, if they do not exist:
SettingsDB.SQLExecute "CREATE TABLE IF NOT EXISTS UserSettings (ID
integer NOT NULL PRIMARY KEY," + _
"Section VARCHAR," + _
"Key VARCHAR," + _
"Value VARCHAR);"
if SettingsDB.ErrorCode <> 0 then
LogError "Error creating table UserSettings: " +
Str(SettingsDB.ErrorCode) + " (" + SettingsDB.ErrorMessage + ")"
return false
End If
// Create indexes, if they do not exist:
SettingsDB.SQLExecute "CREATE INDEX IF NOT EXISTS idxSection ON
UserSettings (Section);"
if SettingsDB.ErrorCode <> 0 then
LogError "Error creating index idxSection: " +
Str(SettingsDB.ErrorCode) + " (" + SettingsDB.ErrorMessage + ")"
return false
End If
SettingsDB.SQLExecute "CREATE INDEX IF NOT EXISTS idxKey ON
UserSettings (Key);"
if SettingsDB.ErrorCode <> 0 then
LogError "Error creating index idxKey: " + Str(SettingsDB.ErrorCode)
+ " (" + SettingsDB.ErrorMessage + ")"
return false
End If

return true

End Function

Sub SaveSetting(Section As String, Key As String, Value As String)
SettingsDB.SQLExecute "DELETE FROM UserSettings WHERE Section='" +
Section + "' AND Key='" + Key + "';"
If SettingsDB.Error Then
LogError SettingsDB.ErrorMessage
End If

SettingsDB.SQLExecute "INSERT INTO UserSettings (Section,Key,Value)
VALUES ('" + Section + "','" + Key + "','" + Value + "');"
If SettingsDB.Error Then
LogError SettingsDB.ErrorMessage
End If

End Sub

Function GetSetting(Section As String, Key as String, Default As String)
As String
dim rs as recordset
dim value As String

value = Default

rs = SettingsDB.SQLSelect("SELECT Value FROM UserSettings WHERE
Section='" + Section + "' AND Key='" + Key + "';" )
If SettingsDB.Error Then
LogError SettingsDB.ErrorMessage
Return value
End If

if rs <> nil Then
If rs.RecordCount > 0 Then
Value = rs.Field("Value")
End If
rs.Close
End If

Return value

End Function

Hope this may be helpful to anyone.
Regards,
Jan-Ivar Mellingen


Jason Glazer skrev:
> Sorry for such a simple question. I'm just getting started using
> REALbasic after years of using VB.
>
> What is the easiest way to store information about application
> settings between times the application is used that will work on all
> platforms?
>
> I want to store some information about a list of files and some user
> options. For Windows, I would use the registry but I would like, if
> possible, a single way to store such settings using REALbasic.
>
> Jason
>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 20:22 (Wed, 5 Aug 2009 13:22:42 -0600)
From: Norman Palardy

On 5-Aug-09, at 11:23 AM, Tim Jones wrote:

> Unfortunately, based on the mail I've received both on list and off
> list, many of you have misinterpreted my support for a plaintext
> prefs files as stating that our users are always editing them. This
> is not the case at all and we hardly ever get to that point with the
> 99th percentile of our users. However, there are unexpected
> circumstances where having an easily editable file can save a
> customer's work and it's being able to provide that for the 1 in 100
> that makes this a good thing in my eyes - and we still have the
> option of saying "toss the prefs file" if that makes sense. The key
> is that we do have options.

Agreed .... plain text is nice as it does give you a way to deal with
that small percentage of situations where nothing else seems to work

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 19:45 (Wed, 05 Aug 2009 20:45:32 +0200)
From: Arnaud Nicolet
Le 5 août 09 à 20:38, Tim Jones a écrit:

> On Aug 5, 2009, at 11:25 AM, Arnaud Nicolet wrote:
>
>>> So, to the 8 people who decided to berate me off list, please get
>>> over it. I do not have a gun to your head and I'm not making
>>> claims that your way is wrong.
>>
>> I didn't thought there would have something to be said offlist on
>> the subject...
>
> Neither did I.
>
> I'm glad that some of us can carry on a conversation without it
> turning impolite :-).

Indeed. As for replying offlist, I don't like that either (often,
it's not really messages that have good reasons to be hidden for the
rest of the mailing list users).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 19:38 (Wed, 5 Aug 2009 11:38:23 -0700)
From: Tim Jones
On Aug 5, 2009, at 11:25 AM, Arnaud Nicolet wrote:

>> So, to the 8 people who decided to berate me off list, please get
>> over it. I do not have a gun to your head and I'm not making
>> claims that your way is wrong.
>
> I didn't thought there would have something to be said offlist on
> the subject...

Neither did I.

I'm glad that some of us can carry on a conversation without it
turning impolite :-).

TIm

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 19:25 (Wed, 05 Aug 2009 20:25:26 +0200)
From: Arnaud Nicolet
Le 5 août 09 à 19:23, Tim Jones a écrit:

> However, there are unexpected circumstances where having an easily
> editable file can save a customer's work and it's being able to
> provide that for the 1 in 100 that makes this a good thing in my
> eyes - and we still have the option of saying "toss the prefs
> file" if that makes sense. The key is that we do have options.

Such a file (editable by the user), should then be a "support" file
(i.e. a file in the Applications Support folder). Well, I'm unsure
about the Applications Support folder, but not the Preferences folder
anyway.

> So, to the 8 people who decided to berate me off list, please get
> over it. I do not have a gun to your head and I'm not making
> claims that your way is wrong.

I didn't thought there would have something to be said offlist on the
subject...
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 18:23 (Wed, 5 Aug 2009 10:23:48 -0700)
From: Tim Jones
On Aug 5, 2009, at 10:09 AM, Norman Palardy wrote:

> Some companies took the attitude that "Hey your a sysadmin and this
> is your job" with their software
>
> Others had the attitude that "our software should help make your
> job as easy as possible where we can"
>
> I happened to really like the companies that landed in the second
> group as I had way more than enough work to do without having to
> edit config files.

We fall into the latter here and our customers agree. We work very
hard to make things as easy as possible for the user (it should just
work), but even the best laid plans of mice and men can get sideways
at times.

Unfortunately, based on the mail I've received both on list and off
list, many of you have misinterpreted my support for a plaintext
prefs files as stating that our users are always editing them. This
is not the case at all and we hardly ever get to that point with the
99th percentile of our users. However, there are unexpected
circumstances where having an easily editable file can save a
customer's work and it's being able to provide that for the 1 in 100
that makes this a good thing in my eyes - and we still have the
option of saying "toss the prefs file" if that makes sense. The key
is that we do have options.

If you prefer the "throw away and start over" method, and it works
for you, excellent. I just don't see that as a 100% answer and was
sharing the method we use as an another option in Arnaud's quest for
answers.

So, to the 8 people who decided to berate me off list, please get
over it. I do not have a gun to your head and I'm not making claims
that your way is wrong.

Geesh!

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 18:09 (Wed, 5 Aug 2009 11:09:08 -0600)
From: Norman Palardy

On 5-Aug-09, at 9:23 AM, Bart Silverstrim wrote:

> Really? I used to edit my win.ini and system.ini files all the time
> to enable and disable features back in the day of win 3.x...actually
> you could alter a lot of behaviors of programs with the .ini files.
>
> With Linux editing .conf files are usually just expected.
>
> On a Mac, no, it's not expected, because the Mac is geared towards
> user friendliness and users don't CARE about things like that. They
> don't want to learn about it any more than your average consumer
> wants to learn how to bleed brakes or change sparkplugs or install a
> washer. I get a sense of accomplishment from doing it. Most people
> don't.
>
> Having your users be guided step by step through editing files and
> altering things could, arguably, be seen as a drawback or feature
> lacking in your program, since I have seen arguments that anything
> in a preference should be alterable from a menu in the program. If
> something's corrupt then that person was arguing that your program
> should be sanity-checking it at startup.
>
> But still, the heart of the argument comes from the point of view of
> the target user. Mac people want "Just Works", and the interface is
> geared for that. Linux people are sysadmins and techs that generally
> know a sshd from a hacksaw. Windows people are typically the
> technoilliterate that want the computer to run the software they
> typically find for the least effort and have less emphasis on "just
> works" or they'd be Mac people...these people come with differing
> expectations but in the end they all want it to just work. Mac
> people have higher standards. Windows people are continually
> frazzled no matter what. Linux people...are weird. They probably
> enjoy playing with your config files.
>
> At least that's been my experiences. I've met plenty who disagree
> and I've met plenty who agree. Free advice is worth what you paid.

As an ex-sysadmin for about 100 VMS machines and about 40 Sun's I
really appreciated systems that did NOT require me to locate and
manually edit config files to make the software work properly.

Some companies took the attitude that "Hey your a sysadmin and this is
your job" with their software

Others had the attitude that "our software should help make your job
as easy as possible where we can"

I happened to really like the companies that landed in the second
group as I had way more than enough work to do without having to edit
config files.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 17:22 (Wed, 05 Aug 2009 18:22:12 +0200)
From: Arnaud Nicolet
Le 5 août 09 à 17:44, Tim Jones a écrit:

> On Aug 5, 2009, at 2:03 AM, Arnaud Nicolet wrote:
>
>> Le 5 août 09 à 24:51, Tim Jones a écrit:
>>
>>>> There are times, indeed, where a popup menu has debug code and
>>>> is hidden in the built application (or some kind of similar
>>>> approaches).
>>>
>>> That's where the App.StageCode variable comes in for your
>>> projects. You get 4 levels and I use the value during builds to
>>> turn my debug-specific things off for a release build. Works
>>> like a charm and there's no opportunity for users to access
>>> things they shouldn't. That means I don't need to hide anything.
>>
>> Well, I don't have app.StageCode in my RB 5.5 application ;-)
>
> You could create a boolean constant in the App class for this
> purpose (maybe call it "Released". Then set it to False for your
> debug or prerelease app builds and then to True for the release
> build. You can then wrap those elements that shouldn't be
> available at release with:
>
> if Not App.Released then
> // do the non-release stuff
> end if

Indeed. I have never had to hide something in the prefs file with my
binary files, so I usually left all in the app.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 17:20 (Wed, 05 Aug 2009 18:20:17 +0200)
From: Arnaud Nicolet
Le 5 août 09 à 17:23, Bart Silverstrim a écrit:

> Joe Huber wrote:
>> At 2:15 PM -0700 8/4/09, <email address removed> wrote:
>>> Since it used a plain text file, however, I was able
>>> to see that the camera resolution was being detected at some
>>> ridiculous
>>> number, fix it, then use the app. Turned out to be an issue with
>>> certain
>>> cameras.
>> It's worth pointing out that this didn't actually solve the
>> problem, it's just a hack to work around it and leaves the user
>> with a brittle environment that can easily break. That app and
>> camera are still incompatible. If that user ever deletes that
>> prefs file or tries to use that combo on another computer it will
>> 'mysteriously' not work.
>> If a prefs file gets messed up, then manually editing it has not
>> solved the root problem.
>> I happen to use a text based prefs file in my apps to help me
>> track and debug things. But I would never consider it appropriate
>> to have a user edit it directly. And we still get accolades for
>> our good support. :-)
>
> Really? I used to edit my win.ini and system.ini files all the time
> to enable and disable features back in the day of win
> 3.x...actually you could alter a lot of behaviors of programs with
> the .ini files.
>
> With Linux editing .conf files are usually just expected.
>
> On a Mac, no, it's not expected, because the Mac is geared towards
> user friendliness and users don't CARE about things like that. They
> don't want to learn about it any more than your average consumer
> wants to learn how to bleed brakes or change sparkplugs or install
> a washer. I get a sense of accomplishment from doing it. Most
> people don't.
>
> Having your users be guided step by step through editing files and
> altering things could, arguably, be seen as a drawback or feature
> lacking in your program, since I have seen arguments that anything
> in a preference should be alterable from a menu in the program. If
> something's corrupt then that person was arguing that your program
> should be sanity-checking it at startup.
>
> But still, the heart of the argument comes from the point of view
> of the target user. Mac people want "Just Works", and the interface
> is geared for that. Linux people are sysadmins and techs that
> generally know a sshd from a hacksaw. Windows people are typically
> the technoilliterate that want the computer to run the software
> they typically find for the least effort and have less emphasis on
> "just works" or they'd be Mac people...these people come with
> differing expectations but in the end they all want it to just
> work. Mac people have higher standards. Windows people are
> continually frazzled no matter what. Linux people...are weird. They
> probably enjoy playing with your config files.
>
> At least that's been my experiences. I've met plenty who disagree
> and I've met plenty who agree. Free advice is worth what you paid.

Your explanation seems wonderful to me.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 17:01 (Wed, 5 Aug 2009 09:01:27 -0700)
From: Joe Huber
At 8:25 AM -0700 8/5/09, Tim Jones wrote:
>It's obvious that you've misunderstood the purpose of what I'm
>sharing with Arnaud.

Hi Tim

I think I got your point...You're willing to use hacks to workaround
a problem, I'm not, nor would I want someone to use that approach
with my mother.

Editing a prefs file does not solve the problem, it just deflects and
defers the pain. The real question is how to prevent and accommodate
munged prefs files in the first place.

If going back to 'ground zero' is the most reliable approach then so
be it. In fact during startup, if my app detects a problem with the
prefs file it offers to reset it to factory defaults so the user
doesn't even have to figure out where the prefs file is located.

I also don't think that the data accumulated in a preferences file
should be all that earth shattering. It should simply be preferences
that are accumulated during normal use of the app.

If your app takes lots of configuration to get right, and that data
would be lost by deleting the prefs file, then you have a bigger
architectural problem than whether the prefs file is editable.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 16:44 (Wed, 5 Aug 2009 08:44:43 -0700)
From: Tim Jones
On Aug 5, 2009, at 2:03 AM, Arnaud Nicolet wrote:

> Le 5 août 09 à 24:51, Tim Jones a écrit:
>
>>> There are times, indeed, where a popup menu has debug code and is
>>> hidden in the built application (or some kind of similar
>>> approaches).
>>
>> That's where the App.StageCode variable comes in for your
>> projects. You get 4 levels and I use the value during builds to
>> turn my debug-specific things off for a release build. Works like
>> a charm and there's no opportunity for users to access things they
>> shouldn't. That means I don't need to hide anything.
>
> Well, I don't have app.StageCode in my RB 5.5 application ;-)

You could create a boolean constant in the App class for this purpose
(maybe call it "Released". Then set it to False for your debug or
prerelease app builds and then to True for the release build. You
can then wrap those elements that shouldn't be available at release
with:

if Not App.Released then
// do the non-release stuff
end if

[snip]

>> As I said, in today's economy, it's all about the customer service.
>
> It's a great level support, indeed.

Our customers seem to agree :-).

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 16:25 (Wed, 5 Aug 2009 08:25:42 -0700)
From: Tim Jones
On Aug 4, 2009, at 6:44 PM, Joe Huber wrote:

> At 1:55 PM -0700 8/4/09, Tim Jones wrote:
>> If the change requires hand holding through a vi session (Unix) or
>> a TextEdit session, we do what is needed to get the user back on
>> track without discarding the entire thing and sending the user
>> back to the beginning.
>
> This approach is for hackers. It's very appropriate if you sell to
> the tinkerer / hacker / Unix market.

It's obvious that you've misunderstood the purpose of what I'm
sharing with Arnaud.

We don't "want" the user to simply discard the preferences / settings
when modifying one entry could solve any issue they are running
into. This is not done because we "want" the user to access our
solutions from a command line environment, but rather to demonstrate
the difference between Apple's "get to the next caller as quickly as
possible" drive which usually means trashing the preferences and our
team's willingness to work with the user to get a true resolution -
even if it means taking the terminal path.

That is the gist of my side of the preferences file discussion.

On Aug 4, 2009, at 6:46 PM, Joe Huber wrote:

> At 3:51 PM -0700 8/4/09, Tim Jones wrote:
>> Our support team will walk a novice user completely through a vi
>> session to change a single option if that's what it takes. It's
>> all about what level of support you provide to your customers.
>>
>> We have a plaque in support that reads:
>>
>> "How would you answer your mother if she were asking the question?"
>>
>> As I said, in today's economy, it's all about the customer service.
>
> I would consider that torture and would NEVER put my mother through
> it. :-)
>
> If you expect a user to be able to change it, then it should have
> an appropriate UI.

As to the slogan, if hand-holding your mom through a simple edit
session made the difference between her using your app and having to

a) go back to ground zero after using it and getting her
configuration "just right", or
b) uninstalling and not using your app

Wouldn't you offer the help?

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 16:06 (Wed, 5 Aug 2009 08:06:46 -0700)
From: Joe Huber
At 2:15 PM -0700 8/4/09, <email address removed> wrote:
>Since it used a plain text file, however, I was able
>to see that the camera resolution was being detected at some ridiculous
>number, fix it, then use the app. Turned out to be an issue with certain
>cameras.

It's worth pointing out that this didn't actually solve the problem,
it's just a hack to work around it and leaves the user with a brittle
environment that can easily break. That app and camera are still
incompatible. If that user ever deletes that prefs file or tries to
use that combo on another computer it will 'mysteriously' not work.

If a prefs file gets messed up, then manually editing it has not
solved the root problem.

I happen to use a text based prefs file in my apps to help me track
and debug things. But I would never consider it appropriate to have a
user edit it directly. And we still get accolades for our good
support. :-)

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 16:23 (Wed, 05 Aug 2009 11:23:58 -0400)
From: Bart Silverstrim
Joe Huber wrote:
> At 2:15 PM -0700 8/4/09, <email address removed> wrote:
>> Since it used a plain text file, however, I was able
>> to see that the camera resolution was being detected at some ridiculous
>> number, fix it, then use the app. Turned out to be an issue with certain
>> cameras.
>
> It's worth pointing out that this didn't actually solve the problem,
> it's just a hack to work around it and leaves the user with a brittle
> environment that can easily break. That app and camera are still
> incompatible. If that user ever deletes that prefs file or tries to use
> that combo on another computer it will 'mysteriously' not work.
>
> If a prefs file gets messed up, then manually editing it has not solved
> the root problem.
>
> I happen to use a text based prefs file in my apps to help me track and
> debug things. But I would never consider it appropriate to have a user
> edit it directly. And we still get accolades for our good support. :-)

Really? I used to edit my win.ini and system.ini files all the time to
enable and disable features back in the day of win 3.x...actually you
could alter a lot of behaviors of programs with the .ini files.

With Linux editing .conf files are usually just expected.

On a Mac, no, it's not expected, because the Mac is geared towards user
friendliness and users don't CARE about things like that. They don't
want to learn about it any more than your average consumer wants to
learn how to bleed brakes or change sparkplugs or install a washer. I
get a sense of accomplishment from doing it. Most people don't.

Having your users be guided step by step through editing files and
altering things could, arguably, be seen as a drawback or feature
lacking in your program, since I have seen arguments that anything in a
preference should be alterable from a menu in the program. If
something's corrupt then that person was arguing that your program
should be sanity-checking it at startup.

But still, the heart of the argument comes from the point of view of the
target user. Mac people want "Just Works", and the interface is geared
for that. Linux people are sysadmins and techs that generally know a
sshd from a hacksaw. Windows people are typically the technoilliterate
that want the computer to run the software they typically find for the
least effort and have less emphasis on "just works" or they'd be Mac
people...these people come with differing expectations but in the end
they all want it to just work. Mac people have higher standards. Windows
people are continually frazzled no matter what. Linux people...are
weird. They probably enjoy playing with your config files.

At least that's been my experiences. I've met plenty who disagree and
I've met plenty who agree. Free advice is worth what you paid.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 10:04 (Wed, 05 Aug 2009 11:04:55 +0200)
From: Arnaud Nicolet
Le 5 août 09 à 3:46, Joe Huber a écrit:

> At 3:51 PM -0700 8/4/09, Tim Jones wrote:
>> Our support team will walk a novice user completely through a vi
>> session to change a single option if that's what it takes. It's
>> all about what level of support you provide to your customers.
>>
>> We have a plaque in support that reads:
>>
>> "How would you answer your mother if she were asking the question?"
>>
>> As I said, in today's economy, it's all about the customer service.
>
> I would consider that torture and would NEVER put my mother through
> it. :-)
>
> If you expect a user to be able to change it, then it should have
> an appropriate UI.

That's also my opinion. Then, it doesn't hurt to have a binary file.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 10:03 (Wed, 05 Aug 2009 11:03:24 +0200)
From: Arnaud Nicolet
Le 5 août 09 à 24:51, Tim Jones a écrit:

>> There are times, indeed, where a popup menu has debug code and is
>> hidden in the built application (or some kind of similar approaches).
>
> That's where the App.StageCode variable comes in for your
> projects. You get 4 levels and I use the value during builds to
> turn my debug-specific things off for a release build. Works like
> a charm and there's no opportunity for users to access things they
> shouldn't. That means I don't need to hide anything.

Well, I don't have app.StageCode in my RB 5.5 application ;-)

>>> As for the user placing an invalid value in the file, aren't you
>>> checking them before simply loading them and using them?
>>
>> I'd be better to not allow the user to easily modify the file and
>> don't be worry with this possible fact ;-)
>
> I check the values even when I know the app is the only thing
> writing them. Better safe than sorry and it adds very little code
> in addition to the normal load features to keep things sane.

I'll see if it's applicable in my current applications.

>>> Just be aware that hiding settings makes that a target for
>>> crackers - sort of like say "I've hidden my settings, so I dare
>>> you to change them."
>>
>> I agree. However, the Finder, the Dock, and plenty of apps do so
>> (you can then control these settings with an app such as "Mac
>> Pilot" or "TinkerTool").
>
> I use the "defaults" tool to modify those app settings (and many
> others) all the time and it's included with OS X.

I don't like the terminal that much. It's not in my habits (which I
won't change when there is another solution, in this case, GUI apps).
Still, I agree that using the terminal can help if you like it.

>>>> (well, I admit it has more to do with the habit than with having
>>>> learnt the subject. Still, why Apple chose that way, then?)
>>>
>>> I stand behind my statement that it's the easiest path and
>>> Apple's support team need to get one user off the phone so that
>>> they can get to the next as quickly as possible.
>>
>> Well, the easier, it's true, but it's also the less confusing.
>> Most users can trash a prefs file. Less can edit them, especially
>> when they don't know what value they have to change and what is
>> the (or one of the) replacement value(s).
>
> Since you were asking about Apple's attitude there, that is all I
> was responding about. Our support team will walk a novice user
> completely through a vi session to change a single option if that's
> what it takes. It's all about what level of support you provide to
> your customers.
>
> We have a plaque in support that reads:
>
> "How would you answer your mother if she were asking the question?"
>
> As I said, in today's economy, it's all about the customer service.

It's a great level support, indeed.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 02:44 (Tue, 4 Aug 2009 18:44:16 -0700)
From: Joe Huber
At 1:55 PM -0700 8/4/09, Tim Jones wrote:
>If the change requires hand holding through a vi session (Unix) or a
>TextEdit session, we do what is needed to get the user back on track
>without discarding the entire thing and sending the user back to the
>beginning.

This approach is for hackers. It's very appropriate if you sell to
the tinkerer / hacker / Unix market.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 05.08.09 02:46 (Tue, 4 Aug 2009 18:46:36 -0700)
From: Joe Huber
At 3:51 PM -0700 8/4/09, Tim Jones wrote:
>Our support team will walk a novice user completely through a vi
>session to change a single option if that's what it takes. It's all
>about what level of support you provide to your customers.
>
>We have a plaque in support that reads:
>
> "How would you answer your mother if she were asking the question?"
>
>As I said, in today's economy, it's all about the customer service.

I would consider that torture and would NEVER put my mother through it. :-)

If you expect a user to be able to change it, then it should have an
appropriate UI.

Regards,
Joe Huber

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 23:51 (Tue, 4 Aug 2009 15:51:31 -0700)
From: Tim Jones
On Aug 4, 2009, at 2:57 PM, Arnaud Nicolet wrote:

> Le 4 août 09 à 23:48, Tim Jones a écrit:
>
>> On Aug 4, 2009, at 2:32 PM, Arnaud Nicolet wrote:
>>
>>>> Here's a question then: Why would you deny the option to fix
>>>> that file to a user? Why use a format that forces a choice on
>>>> someone when you don't have to? It isn't like you can't throw a
>>>> text file away, but you sure as hell don't want to edit a binary
>>>> file in a text editor.
>>>
>>> Perhaps because the user could then write worse values when the
>>> file is fine, or making some testings I don't want them to do.
>>>
>>> If the user enters a value I didn't expect and finds a bug (or
>>> discovers something about my app), I'm not happy either. I'd call
>>> this "copyright" violations. Granted, an advanced user will
>>> always be able to modify one prefs file (by looking at how it is
>>> written), but it's a security addition (like a password).
>>
>> Aha - and therein lies the true issue for you. Security by
>> obfuscation. I seems that you are placing values into your
>> preferences files that could allow a user to manipulate your
>> applications in a manner that they should not.
>
> There are times, indeed, where a popup menu has debug code and is
> hidden in the built application (or some kind of similar approaches).

That's where the App.StageCode variable comes in for your projects.
You get 4 levels and I use the value during builds to turn my debug-
specific things off for a release build. Works like a charm and
there's no opportunity for users to access things they shouldn't.
That means I don't need to hide anything.

>> As for the user placing an invalid value in the file, aren't you
>> checking them before simply loading them and using them?
>
> I'd be better to not allow the user to easily modify the file and
> don't be worry with this possible fact ;-)

I check the values even when I know the app is the only thing writing
them. Better safe than sorry and it adds very little code in
addition to the normal load features to keep things sane.

>> Just be aware that hiding settings makes that a target for
>> crackers - sort of like say "I've hidden my settings, so I dare
>> you to change them."
>
> I agree. However, the Finder, the Dock, and plenty of apps do so
> (you can then control these settings with an app such as "Mac
> Pilot" or "TinkerTool").

I use the "defaults" tool to modify those app settings (and many
others) all the time and it's included with OS X.

>>> (well, I admit it has more to do with the habit than with having
>>> learnt the subject. Still, why Apple chose that way, then?)
>>
>> I stand behind my statement that it's the easiest path and Apple's
>> support team need to get one user off the phone so that they can
>> get to the next as quickly as possible.
>
> Well, the easier, it's true, but it's also the less confusing. Most
> users can trash a prefs file. Less can edit them, especially when
> they don't know what value they have to change and what is the (or
> one of the) replacement value(s).

Since you were asking about Apple's attitude there, that is all I was
responding about. Our support team will walk a novice user
completely through a vi session to change a single option if that's
what it takes. It's all about what level of support you provide to
your customers.

We have a plaque in support that reads:

"How would you answer your mother if she were asking the question?"

As I said, in today's economy, it's all about the customer service.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 22:57 (Tue, 04 Aug 2009 23:57:50 +0200)
From: Arnaud Nicolet
Le 4 août 09 à 23:48, Tim Jones a écrit:

> On Aug 4, 2009, at 2:32 PM, Arnaud Nicolet wrote:
>
>>> Here's a question then: Why would you deny the option to fix that
>>> file to a user? Why use a format that forces a choice on someone
>>> when you don't have to? It isn't like you can't throw a text file
>>> away, but you sure as hell don't want to edit a binary file in a
>>> text editor.
>>
>> Perhaps because the user could then write worse values when the
>> file is fine, or making some testings I don't want them to do.
>>
>> If the user enters a value I didn't expect and finds a bug (or
>> discovers something about my app), I'm not happy either. I'd call
>> this "copyright" violations. Granted, an advanced user will always
>> be able to modify one prefs file (by looking at how it is
>> written), but it's a security addition (like a password).
>
> Aha - and therein lies the true issue for you. Security by
> obfuscation. I seems that you are placing values into your
> preferences files that could allow a user to manipulate your
> applications in a manner that they should not.

There are times, indeed, where a popup menu has debug code and is
hidden in the built application (or some kind of similar approaches).

> As for the user placing an invalid value in the file, aren't you
> checking them before simply loading them and using them?

I'd be better to not allow the user to easily modify the file and
don't be worry with this possible fact ;-)

> Just be aware that hiding settings makes that a target for crackers
> - sort of like say "I've hidden my settings, so I dare you to
> change them."

I agree. However, the Finder, the Dock, and plenty of apps do so (you
can then control these settings with an app such as "Mac Pilot" or
"TinkerTool").

>> (well, I admit it has more to do with the habit than with having
>> learnt the subject. Still, why Apple chose that way, then?)
>
> I stand behind my statement that it's the easiest path and Apple's
> support team need to get one user off the phone so that they can
> get to the next as quickly as possible.

Well, the easier, it's true, but it's also the less confusing. Most
users can trash a prefs file. Less can edit them, especially when
they don't know what value they have to change and what is the (or
one of the) replacement value(s).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 22:51 (Tue, 04 Aug 2009 23:51:56 +0200)
From: Arnaud Nicolet
Le 4 août 09 à 23:43, Tim Jones a écrit:

>>> Allow me to share a story. There's an app called... wxCam? or
>>> somesuch.. that a friend of mine installed to use her webcam to
>>> record via motion triggering. Installed fine, went to run it and
>>> it would do nothing but segfault. Ok, fine. Uninstalled it,
>>> cleared the config and user files, double checked dependencies,
>>> reinstalled. Same thing.
>>>
>>> Now, if the app stored everything in some inscrutable format,
>>> that app would have had to go bye bye, nice features or no,
>>> because it was completely unusable. Since it used a plain text
>>> file, however, I was able to see that the camera resolution was
>>> being detected at some ridiculous number, fix it, then use the
>>> app. Turned out to be an issue with certain cameras.
>>>
>>> Would this apply to all situations? No, obviously not, but it's a
>>> very good example of why you might as well suck it up and use
>>> something easily edited. Things go wrong, even with a pristine
>>> application, and being afraid of users editing the file is either
>>> baseless paranoia or bad error handling.
>>
>> Fine, but what if your friend or you trashed the prefs file? Two
>> scenarios come to mind:
>> 1: the app would recreate the prefs file (as it should) and things
>> would certainly run fine again.
>
> Not in Fargo's example. The app was getting the wrong info from
> the camera.

Correct. The app could have detected that and corrected with (or
asked for) good values, then.

>> 2: if the app is bad written, it recreates the prefs file with the
>> bad values and the crash occurs again. Granted, editing the file
>> would solve the problem, but the fault is the application in that
>> case and it should be rewritten.
>
> In this case, by being able to edit the prefs file, Fargo and his
> friend were able to reset a proper value for the camera resolution
> and use an otherwise good application.

I agree.

>> I'm not really afraid of users editing (while, I admit, I want to
>> prevent as much as possible the user entering bad data in my prefs
>> files), but it's not the way Mac users have learnt (in Mac OS 9,
>> there was no terminal, and not such app as TextEdit to open any
>> kind of files (installed by Apple, of course). It's logical Mac OS
>> 9 users have learnt to trash the file, and I still see this
>> logical, as I don't want to possibly enter a worse value in a
>> prefs file).
>
> Apple made a lot of poor calls in the older MacOS versions. One of
> the first things I added to all of my old Macs was a text editor
> and a hex editor. Those two simple tools saved many hours of
> effort in Quark, Illustrator, and other apps. Back then, I was
> paid by the job and having to start with Quark Xpress back at
> ground zero could set a project back 4 or more hours. That could
> translate to 4 hours that I was NOT working on another project.
>
> As Fargo mentioned in another post, the user can discard a text-
> based preference file as readily as they can discard a binary
> file. I'd rather offer the option of fixing a simple issue.

I'm not convinced, but your opinion is valid anyway.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 22:48 (Tue, 4 Aug 2009 14:48:15 -0700)
From: Tim Jones
On Aug 4, 2009, at 2:32 PM, Arnaud Nicolet wrote:

>> Here's a question then: Why would you deny the option to fix that
>> file to a user? Why use a format that forces a choice on someone
>> when you don't have to? It isn't like you can't throw a text file
>> away, but you sure as hell don't want to edit a binary file in a
>> text editor.
>
> Perhaps because the user could then write worse values when the
> file is fine, or making some testings I don't want them to do.
>
> If the user enters a value I didn't expect and finds a bug (or
> discovers something about my app), I'm not happy either. I'd call
> this "copyright" violations. Granted, an advanced user will always
> be able to modify one prefs file (by looking at how it is written),
> but it's a security addition (like a password).

Aha - and therein lies the true issue for you. Security by
obfuscation. I seems that you are placing values into your
preferences files that could allow a user to manipulate your
applications in a manner that they should not.

As for the user placing an invalid value in the file, aren't you
checking them before simply loading them and using them?

Just be aware that hiding settings makes that a target for crackers -
sort of like say "I've hidden my settings, so I dare you to change
them."

> (well, I admit it has more to do with the habit than with having
> learnt the subject. Still, why Apple chose that way, then?)

I stand behind my statement that it's the easiest path and Apple's
support team need to get one user off the phone so that they can get
to the next as quickly as possible.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 22:43 (Tue, 4 Aug 2009 14:43:43 -0700)
From: Tim Jones
>>> Usually, a Mac user would simply trash the prefs file when the
>>> app goes wrong (it's what Apple usually suggests). I say it
>>> again, a binary file is also fine (and you can write/read
>>> booleans, integers, etc. out of the box).
>>
>> Allow me to share a story. There's an app called... wxCam? or
>> somesuch.. that a friend of mine installed to use her webcam to
>> record via motion triggering. Installed fine, went to run it and
>> it would do nothing but segfault. Ok, fine. Uninstalled it,
>> cleared the config and user files, double checked dependencies,
>> reinstalled. Same thing.
>>
>> Now, if the app stored everything in some inscrutable format, that
>> app would have had to go bye bye, nice features or no, because it
>> was completely unusable. Since it used a plain text file, however,
>> I was able to see that the camera resolution was being detected at
>> some ridiculous number, fix it, then use the app. Turned out to be
>> an issue with certain cameras.
>>
>> Would this apply to all situations? No, obviously not, but it's a
>> very good example of why you might as well suck it up and use
>> something easily edited. Things go wrong, even with a pristine
>> application, and being afraid of users editing the file is either
>> baseless paranoia or bad error handling.
>
> Fine, but what if your friend or you trashed the prefs file? Two
> scenarios come to mind:
> 1: the app would recreate the prefs file (as it should) and things
> would certainly run fine again.

Not in Fargo's example. The app was getting the wrong info from the
camera.

> 2: if the app is bad written, it recreates the prefs file with the
> bad values and the crash occurs again. Granted, editing the file
> would solve the problem, but the fault is the application in that
> case and it should be rewritten.

In this case, by being able to edit the prefs file, Fargo and his
friend were able to reset a proper value for the camera resolution
and use an otherwise good application.

> I'm not really afraid of users editing (while, I admit, I want to
> prevent as much as possible the user entering bad data in my prefs
> files), but it's not the way Mac users have learnt (in Mac OS 9,
> there was no terminal, and not such app as TextEdit to open any
> kind of files (installed by Apple, of course). It's logical Mac OS
> 9 users have learnt to trash the file, and I still see this
> logical, as I don't want to possibly enter a worse value in a prefs
> file).

Apple made a lot of poor calls in the older MacOS versions. One of
the first things I added to all of my old Macs was a text editor and
a hex editor. Those two simple tools saved many hours of effort in
Quark, Illustrator, and other apps. Back then, I was paid by the job
and having to start with Quark Xpress back at ground zero could set a
project back 4 or more hours. That could translate to 4 hours that I
was NOT working on another project.

As Fargo mentioned in another post, the user can discard a text-based
preference file as readily as they can discard a binary file. I'd
rather offer the option of fixing a simple issue.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 22:32 (Tue, 04 Aug 2009 23:32:54 +0200)
From: Arnaud Nicolet
Le 4 août 09 à 23:22, <email address removed> a écrit:

>> I think it's because Apple is not Linux. One guy who use Linux
>> supposedly wants to configure everything on his system, somewhat like
>> a programmer. Then, of course, he may repair a damaged file. Apple
>> usually don't insist on suggesting their users to learn the use of
>> the terminal (it's just a tool that one can learn if he wants).
>>
>> Just my opinion, as a Mac user who sees Linux users from a remote
>> point of view.
>
> Here's a question then: Why would you deny the option to fix that
> file to
> a user? Why use a format that forces a choice on someone when you
> don't
> have to? It isn't like you can't throw a text file away, but you
> sure as
> hell don't want to edit a binary file in a text editor.

Perhaps because the user could then write worse values when the file
is fine, or making some testings I don't want them to do.

If the user enters a value I didn't expect and finds a bug (or
discovers something about my app), I'm not happy either. I'd call
this "copyright" violations. Granted, an advanced user will always be
able to modify one prefs file (by looking at how it is written), but
it's a security addition (like a password).

(well, I admit it has more to do with the habit than with having
learnt the subject. Still, why Apple chose that way, then?)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 22:25 (Tue, 04 Aug 2009 23:25:38 +0200)
From: Arnaud Nicolet
Le 4 août 09 à 23:15, <email address removed> a écrit:

>> Le 4 août 09 à 22:24, Tim Jones a écrit:
>>
>>> On Aug 4, 2009, at 12:35 PM, <email address removed> wrote:
>>>
>>>>> Sorry for such a simple question. I'm just getting started using
>>>>> REALbasic after years of using VB.
>>>>>
>>>>> What is the easiest way to store information about application
>>>>> settings between times the application is used that will work on
>>>>> all platforms?
>>>>>
>>>>> I want to store some information about a list of files and some
>>>>> user options. For Windows, I would use the registry but I would
>>>>> like, if possible, a single way to store such settings using
>>>>> REALbasic.
>>>>>
>>>>> Jason
>>>>
>>>> I'm fond of either plain text key/value pairs or XML.
>>>
>>> Hi Jason,
>>>
>>> I use a little tool named "REALEasyPrefs" (unfortunately it seems
>>> abandoned by its author - Chris Cormeau) and set the platform-
>>> specific prefs file to:
>>>
>>> OS X: SpecialFolder.Preferences.Child("com.tolisgroup.PRODUCTNAME")
>>> Windows: SpecialFolder.Preferences.Child("TOLIS Group").Child
>>> ("PRODUCTNAME")
>>> Linux: SpecialFolder.UserHome.Child(".PRODUCTNAME")
>>>
>>> The file itself is a plain text key value pair as Fargo notes.
>>>
>>> Works like a charm and can be edited by the user in the case things
>>> get sideways in the app.
>>
>> Usually, a Mac user would simply trash the prefs file when the app
>> goes wrong (it's what Apple usually suggests). I say it again, a
>> binary file is also fine (and you can write/read booleans, integers,
>> etc. out of the box).
>
> Allow me to share a story. There's an app called... wxCam? or
> somesuch..
> that a friend of mine installed to use her webcam to record via motion
> triggering. Installed fine, went to run it and it would do nothing but
> segfault. Ok, fine. Uninstalled it, cleared the config and user files,
> double checked dependencies, reinstalled. Same thing.
>
> Now, if the app stored everything in some inscrutable format, that app
> would have had to go bye bye, nice features or no, because it was
> completely unusable. Since it used a plain text file, however, I
> was able
> to see that the camera resolution was being detected at some
> ridiculous
> number, fix it, then use the app. Turned out to be an issue with
> certain
> cameras.
>
> Would this apply to all situations? No, obviously not, but it's a very
> good example of why you might as well suck it up and use something
> easily
> edited. Things go wrong, even with a pristine application, and being
> afraid of users editing the file is either baseless paranoia or bad
> error
> handling.

Fine, but what if your friend or you trashed the prefs file? Two
scenarios come to mind:
1: the app would recreate the prefs file (as it should) and things
would certainly run fine again.
2: if the app is bad written, it recreates the prefs file with the
bad values and the crash occurs again. Granted, editing the file
would solve the problem, but the fault is the application in that
case and it should be rewritten.

I'm not really afraid of users editing (while, I admit, I want to
prevent as much as possible the user entering bad data in my prefs
files), but it's not the way Mac users have learnt (in Mac OS 9,
there was no terminal, and not such app as TextEdit to open any kind
of files (installed by Apple, of course). It's logical Mac OS 9 users
have learnt to trash the file, and I still see this logical, as I
don't want to possibly enter a worse value in a prefs file).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 22:22 (Tue, 4 Aug 2009 14:22:53 -0700 (PDT))
From: fargo rpgportland.com
> Le 4 août 09 à 22:55, Tim Jones a écrit:
>
>> On Aug 4, 2009, at 1:43 PM, Arnaud Nicolet wrote:
>>
>>> Le 4 août 09 à 22:24, Tim Jones a écrit:
>>>
>>>> On Aug 4, 2009, at 12:35 PM, <email address removed> wrote:
>>>>
>>>>>> Sorry for such a simple question. I'm just getting started
>>>>>> using REALbasic after years of using VB.
>>>>>>
>>>>>> What is the easiest way to store information about application
>>>>>> settings between times the application is used that will work
>>>>>> on all platforms?
>>>>>>
>>>>>> I want to store some information about a list of files and some
>>>>>> user options. For Windows, I would use the registry but I would
>>>>>> like, if possible, a single way to store such settings using
>>>>>> REALbasic.
>>>>>>
>>>>>> Jason
>>>>>
>>>>> I'm fond of either plain text key/value pairs or XML.
>>>>
>>>> Hi Jason,
>>>>
>>>> I use a little tool named "REALEasyPrefs" (unfortunately it seems
>>>> abandoned by its author - Chris Cormeau) and set the platform-
>>>> specific prefs file to:
>>>>
>>>> OS X: SpecialFolder.Preferences.Child("com.tolisgroup.PRODUCTNAME")
>>>> Windows: SpecialFolder.Preferences.Child("TOLIS Group").Child
>>>> ("PRODUCTNAME")
>>>> Linux: SpecialFolder.UserHome.Child(".PRODUCTNAME")
>>>>
>>>> The file itself is a plain text key value pair as Fargo notes.
>>>>
>>>> Works like a charm and can be edited by the user in the case
>>>> things get sideways in the app.
>>>
>>> Usually, a Mac user would simply trash the prefs file when the app
>>> goes wrong (it's what Apple usually suggests). I say it again, a
>>> binary file is also fine (and you can write/read booleans,
>>> integers, etc. out of the box).
>>
>> Simply deleting a complex preferences file to fix what could be a
>> minor issue is bad mojo for users. Apple recommends that because
>> Apple support doesn't want to hand-hold walking an end user through
>> an editing session. It's easier for the rep to "fix" the bad entry
>> by instructing the user to toss the whole thing. Our support team
>> doesn't treat end users that way. If the change requires hand
>> holding through a vi session (Unix) or a TextEdit session, we do
>> what is needed to get the user back on track without discarding the
>> entire thing and sending the user back to the beginning.
>>
>> It's all about customer service in today's marketplace.
>
> I think it's because Apple is not Linux. One guy who use Linux
> supposedly wants to configure everything on his system, somewhat like
> a programmer. Then, of course, he may repair a damaged file. Apple
> usually don't insist on suggesting their users to learn the use of
> the terminal (it's just a tool that one can learn if he wants).
>
> Just my opinion, as a Mac user who sees Linux users from a remote
> point of view.

Here's a question then: Why would you deny the option to fix that file to
a user? Why use a format that forces a choice on someone when you don't
have to? It isn't like you can't throw a text file away, but you sure as
hell don't want to edit a binary file in a text editor.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 22:15 (Tue, 4 Aug 2009 14:15:53 -0700 (PDT))
From: fargo rpgportland.com
> Le 4 août 09 à 22:24, Tim Jones a écrit:
>
>> On Aug 4, 2009, at 12:35 PM, <email address removed> wrote:
>>
>>>> Sorry for such a simple question. I'm just getting started using
>>>> REALbasic after years of using VB.
>>>>
>>>> What is the easiest way to store information about application
>>>> settings between times the application is used that will work on
>>>> all platforms?
>>>>
>>>> I want to store some information about a list of files and some
>>>> user options. For Windows, I would use the registry but I would
>>>> like, if possible, a single way to store such settings using
>>>> REALbasic.
>>>>
>>>> Jason
>>>
>>> I'm fond of either plain text key/value pairs or XML.
>>
>> Hi Jason,
>>
>> I use a little tool named "REALEasyPrefs" (unfortunately it seems
>> abandoned by its author - Chris Cormeau) and set the platform-
>> specific prefs file to:
>>
>> OS X: SpecialFolder.Preferences.Child("com.tolisgroup.PRODUCTNAME")
>> Windows: SpecialFolder.Preferences.Child("TOLIS Group").Child
>> ("PRODUCTNAME")
>> Linux: SpecialFolder.UserHome.Child(".PRODUCTNAME")
>>
>> The file itself is a plain text key value pair as Fargo notes.
>>
>> Works like a charm and can be edited by the user in the case things
>> get sideways in the app.
>
> Usually, a Mac user would simply trash the prefs file when the app
> goes wrong (it's what Apple usually suggests). I say it again, a
> binary file is also fine (and you can write/read booleans, integers,
> etc. out of the box).

Allow me to share a story. There's an app called... wxCam? or somesuch..
that a friend of mine installed to use her webcam to record via motion
triggering. Installed fine, went to run it and it would do nothing but
segfault. Ok, fine. Uninstalled it, cleared the config and user files,
double checked dependencies, reinstalled. Same thing.

Now, if the app stored everything in some inscrutable format, that app
would have had to go bye bye, nice features or no, because it was
completely unusable. Since it used a plain text file, however, I was able
to see that the camera resolution was being detected at some ridiculous
number, fix it, then use the app. Turned out to be an issue with certain
cameras.

Would this apply to all situations? No, obviously not, but it's a very
good example of why you might as well suck it up and use something easily
edited. Things go wrong, even with a pristine application, and being
afraid of users editing the file is either baseless paranoia or bad error
handling.

Best,
Fargo

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 22:10 (Tue, 04 Aug 2009 23:10:55 +0200)
From: Arnaud Nicolet
Le 4 août 09 à 22:55, Tim Jones a écrit:

> On Aug 4, 2009, at 1:43 PM, Arnaud Nicolet wrote:
>
>> Le 4 août 09 à 22:24, Tim Jones a écrit:
>>
>>> On Aug 4, 2009, at 12:35 PM, <email address removed> wrote:
>>>
>>>>> Sorry for such a simple question. I'm just getting started
>>>>> using REALbasic after years of using VB.
>>>>>
>>>>> What is the easiest way to store information about application
>>>>> settings between times the application is used that will work
>>>>> on all platforms?
>>>>>
>>>>> I want to store some information about a list of files and some
>>>>> user options. For Windows, I would use the registry but I would
>>>>> like, if possible, a single way to store such settings using
>>>>> REALbasic.
>>>>>
>>>>> Jason
>>>>
>>>> I'm fond of either plain text key/value pairs or XML.
>>>
>>> Hi Jason,
>>>
>>> I use a little tool named "REALEasyPrefs" (unfortunately it seems
>>> abandoned by its author - Chris Cormeau) and set the platform-
>>> specific prefs file to:
>>>
>>> OS X: SpecialFolder.Preferences.Child("com.tolisgroup.PRODUCTNAME")
>>> Windows: SpecialFolder.Preferences.Child("TOLIS Group").Child
>>> ("PRODUCTNAME")
>>> Linux: SpecialFolder.UserHome.Child(".PRODUCTNAME")
>>>
>>> The file itself is a plain text key value pair as Fargo notes.
>>>
>>> Works like a charm and can be edited by the user in the case
>>> things get sideways in the app.
>>
>> Usually, a Mac user would simply trash the prefs file when the app
>> goes wrong (it's what Apple usually suggests). I say it again, a
>> binary file is also fine (and you can write/read booleans,
>> integers, etc. out of the box).
>
> Simply deleting a complex preferences file to fix what could be a
> minor issue is bad mojo for users. Apple recommends that because
> Apple support doesn't want to hand-hold walking an end user through
> an editing session. It's easier for the rep to "fix" the bad entry
> by instructing the user to toss the whole thing. Our support team
> doesn't treat end users that way. If the change requires hand
> holding through a vi session (Unix) or a TextEdit session, we do
> what is needed to get the user back on track without discarding the
> entire thing and sending the user back to the beginning.
>
> It's all about customer service in today's marketplace.

I think it's because Apple is not Linux. One guy who use Linux
supposedly wants to configure everything on his system, somewhat like
a programmer. Then, of course, he may repair a damaged file. Apple
usually don't insist on suggesting their users to learn the use of
the terminal (it's just a tool that one can learn if he wants).

Just my opinion, as a Mac user who sees Linux users from a remote
point of view.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 21:55 (Tue, 4 Aug 2009 13:55:15 -0700)
From: Tim Jones
On Aug 4, 2009, at 1:43 PM, Arnaud Nicolet wrote:

> Le 4 août 09 à 22:24, Tim Jones a écrit:
>
>> On Aug 4, 2009, at 12:35 PM, <email address removed> wrote:
>>
>>>> Sorry for such a simple question. I'm just getting started using
>>>> REALbasic after years of using VB.
>>>>
>>>> What is the easiest way to store information about application
>>>> settings between times the application is used that will work on
>>>> all platforms?
>>>>
>>>> I want to store some information about a list of files and some
>>>> user options. For Windows, I would use the registry but I would
>>>> like, if possible, a single way to store such settings using
>>>> REALbasic.
>>>>
>>>> Jason
>>>
>>> I'm fond of either plain text key/value pairs or XML.
>>
>> Hi Jason,
>>
>> I use a little tool named "REALEasyPrefs" (unfortunately it seems
>> abandoned by its author - Chris Cormeau) and set the platform-
>> specific prefs file to:
>>
>> OS X: SpecialFolder.Preferences.Child("com.tolisgroup.PRODUCTNAME")
>> Windows: SpecialFolder.Preferences.Child("TOLIS Group").Child
>> ("PRODUCTNAME")
>> Linux: SpecialFolder.UserHome.Child(".PRODUCTNAME")
>>
>> The file itself is a plain text key value pair as Fargo notes.
>>
>> Works like a charm and can be edited by the user in the case
>> things get sideways in the app.
>
> Usually, a Mac user would simply trash the prefs file when the app
> goes wrong (it's what Apple usually suggests). I say it again, a
> binary file is also fine (and you can write/read booleans,
> integers, etc. out of the box).

Simply deleting a complex preferences file to fix what could be a
minor issue is bad mojo for users. Apple recommends that because
Apple support doesn't want to hand-hold walking an end user through
an editing session. It's easier for the rep to "fix" the bad entry
by instructing the user to toss the whole thing. Our support team
doesn't treat end users that way. If the change requires hand
holding through a vi session (Unix) or a TextEdit session, we do what
is needed to get the user back on track without discarding the entire
thing and sending the user back to the beginning.

It's all about customer service in today's marketplace.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 21:43 (Tue, 04 Aug 2009 22:43:08 +0200)
From: Arnaud Nicolet
Le 4 août 09 à 22:24, Tim Jones a écrit:

> On Aug 4, 2009, at 12:35 PM, <email address removed> wrote:
>
>>> Sorry for such a simple question. I'm just getting started using
>>> REALbasic after years of using VB.
>>>
>>> What is the easiest way to store information about application
>>> settings between times the application is used that will work on
>>> all platforms?
>>>
>>> I want to store some information about a list of files and some
>>> user options. For Windows, I would use the registry but I would
>>> like, if possible, a single way to store such settings using
>>> REALbasic.
>>>
>>> Jason
>>
>> I'm fond of either plain text key/value pairs or XML.
>
> Hi Jason,
>
> I use a little tool named "REALEasyPrefs" (unfortunately it seems
> abandoned by its author - Chris Cormeau) and set the platform-
> specific prefs file to:
>
> OS X: SpecialFolder.Preferences.Child("com.tolisgroup.PRODUCTNAME")
> Windows: SpecialFolder.Preferences.Child("TOLIS Group").Child
> ("PRODUCTNAME")
> Linux: SpecialFolder.UserHome.Child(".PRODUCTNAME")
>
> The file itself is a plain text key value pair as Fargo notes.
>
> Works like a charm and can be edited by the user in the case things
> get sideways in the app.

Usually, a Mac user would simply trash the prefs file when the app
goes wrong (it's what Apple usually suggests). I say it again, a
binary file is also fine (and you can write/read booleans, integers,
etc. out of the box).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 21:24 (Tue, 4 Aug 2009 13:24:49 -0700)
From: Tim Jones
On Aug 4, 2009, at 12:35 PM, <email address removed> wrote:

>> Sorry for such a simple question. I'm just getting started using
>> REALbasic after years of using VB.
>>
>> What is the easiest way to store information about application
>> settings between times the application is used that will work on
>> all platforms?
>>
>> I want to store some information about a list of files and some
>> user options. For Windows, I would use the registry but I would
>> like, if possible, a single way to store such settings using
>> REALbasic.
>>
>> Jason
>
> I'm fond of either plain text key/value pairs or XML.

Hi Jason,

I use a little tool named "REALEasyPrefs" (unfortunately it seems
abandoned by its author - Chris Cormeau) and set the platform-
specific prefs file to:

OS X: SpecialFolder.Preferences.Child("com.tolisgroup.PRODUCTNAME")
Windows: SpecialFolder.Preferences.Child("TOLIS Group").Child
("PRODUCTNAME")
Linux: SpecialFolder.UserHome.Child(".PRODUCTNAME")

The file itself is a plain text key value pair as Fargo notes.

Works like a charm and can be edited by the user in the case things
get sideways in the app.

If you're interested, I'll bundle up the class I use and send it off
list.

Tim

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 21:15 (Tue, 4 Aug 2009 16:15:11 -0400)
From: Roger Clary

On Aug 4, 2009, at 3:35 PM, <email address removed> wrote:

>> Sorry for such a simple question. I'm just getting started
>> using REALbasic after years of using VB.
>>
>> What is the easiest way to store information about
>> application settings between times the application is used
>> that will work on all platforms?
>>
>> I want to store some information about a list of files and
>> some user options. For Windows, I would use the registry but
>> I would like, if possible, a single way to store such
>> settings using REALbasic.
>

xml file, or RealDB file, or plain text file (opinions vary as to
which is best) written to either
SpecialFolder.sharedPreferences for all users or
SpecialFolder.Preferences for a single user.

Roger Clary
<email address removed>
Class One Software
Educational Software for Lifelong Learning


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 21:08 (Tue, 04 Aug 2009 22:08:15 +0200)
From: Arnaud Nicolet
Le 4 août 09 à 21:35, <email address removed> a écrit:

>> Sorry for such a simple question. I'm just getting started
>> using REALbasic after years of using VB.
>>
>> What is the easiest way to store information about
>> application settings between times the application is used
>> that will work on all platforms?
>>
>> I want to store some information about a list of files and
>> some user options. For Windows, I would use the registry but
>> I would like, if possible, a single way to store such
>> settings using REALbasic.
>>
>> Jason
>
> I'm fond of either plain text key/value pairs or XML.

A binary file is also great (the user isn't concerned about the
content of such files, so, IMHO, it should not be "editable").
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 04.08.09 20:35 (Tue, 4 Aug 2009 12:35:04 -0700 (PDT))
From: fargo rpgportland.com
> Sorry for such a simple question. I'm just getting started
> using REALbasic after years of using VB.
>
> What is the easiest way to store information about
> application settings between times the application is used
> that will work on all platforms?
>
> I want to store some information about a list of files and
> some user options. For Windows, I would use the registry but
> I would like, if possible, a single way to store such
> settings using REALbasic.
>
> Jason

I'm fond of either plain text key/value pairs or XML.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 15.08.09 11:20 (Sat, 15 Aug 2009 12:20:35 +0200)
From: Arnaud Nicolet
Le 15 août 09 à 6:41, Carlos M a écrit:

>> So, if you buy a Mac, I learn databases, and if you don't, I don't
>> (kind of
>> a game to decide me whether I make some efforts or not ;-) ).
>
> You're not going to learn databases...

Fine :-)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 15.08.09 05:41 (Sat, 15 Aug 2009 05:41:13 +0100)
From: Carlos M
On Fri, Aug 14, 2009 at 11:04 AM, Arnaud Nicolet wrote:
> I'm not sure how you would say you're a "complete" programmer if you don't
> try Mac, on the other hand ;-)

Dammit! I'm not going to be a "complete" programmer :(

> So, if you buy a Mac, I learn databases, and if you don't, I don't (kind of
> a game to decide me whether I make some efforts or not ;-) ).

You're not going to learn databases...

Carlos

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 15.08.09 05:16 (Sat, 15 Aug 2009 05:16:09 +0100)
From: Carlos M
On Fri, Aug 14, 2009 at 2:34 AM, Cameron McCormick wrote:
> Um, I donno if you some additional reason for this, but as a windows only
> developer, why not use the registry? That's what its there for...

I use the registry and/or the "Application Data" folder. Sometimes I
only use the registry, other the "Application Data" folder and other a
mix. It depends on the type of apps, the targeted users, the type of
data (and length) and other factors.

> It would
> avoid the user accidentally deleting the settings. Of course it isn't 100%
> foolproof, but the user would have to go out of their way to delete it...

The user would also have "to go out of their way to delete" the data
in the "Application Data" folder. But in the documents folder, yes,
there's a risk of the user accidentally deleting it.

Carlos


> On Wed, Aug 12, 2009 at 8:54 PM, Carlos M wrote:
>
>> On Mon, Aug 10, 2009 at 11:01 AM, Jan-Ivar Mellingen wrote:
>> > I am using the built-in RB database for my settings, just containing a
>> > simple table. It allows me to easy port my old VB5 code, and at the same
>> > time avoid a lot of platform problems.
>>
>> I'm also using this solution for some apps with good results.
>>
>> > I have placed the database file in a folder with full user access,
>> > avoiding any permission problems. A nice side-effect is that the
>> > settings are also copied when the user (hopefully) backs up his
>> > documents (home) folder.
>>
>> I see the advantages in storing the prefs in a folder inside the
>> documents folder. But I see a big disadvantage: if the user does not
>> recognize the folder or associates the folder to your application,
>> he/she might delete it. If I used this approach I would make sure to
>> have inside it a text file named something like "DO NOT DELETE THIS
>> FOLDER AND FILES - READ ME.txt" and explain what the folder is used
>> for... just in case ;-)
>>
>> Being a Windows only developer, I prefer to store the prefs in the
>> user's "Application Data" folder. I'm also implementing a backup
>> system in case a prefs file get corrupted and that is to store in a
>> "backup" sub-folder a copy of the last saved prefs file and keep only
>> there files of the last 30 days or the last 10 files of different
>> days. I named them in the format "YYYYMMDDHHMMSS-backup". I'm also
>> considering giving an option in the software for the user to store a
>> backup of the prefs file in a location they want.
>>
>> > Other folders may be more suitable for settings common to several users
>> > or several applications.
>> Yep...
>>
>> Carlos

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 14.08.09 11:04 (Fri, 14 Aug 2009 12:04:10 +0200)
From: Arnaud Nicolet
Le 14 août 09 à 3:28, Carlos M a écrit:

> On Thu, Aug 13, 2009 at 10:40 AM, Arnaud Nicolet wrote:
>> Le 13 août 09 à 3:58, Carlos M a écrit:
>>
>>> On Mon, Aug 10, 2009 at 7:04 PM, Arnaud Nicolet wrote:
>>>> I have the impression that most guy who speaks about databases
>>>> are coming
>>>> from windows... Do you have the same feeling?
>>>
>>> Nope... but I'm a Windows user and *only* use databases when I think
>>> is the best solution.
>>
>> Well, you're anyway showing that another windows user uses them ;-)
>
> Yep, among many, many more Mac users in this list that are, from my
> perception, the majority ;-)

Well, it seems Mac users prefer, globally, the mailing list and
Windows users prefer the forum (I'm not out of the group as I
strongly dislike forums).

>>>> and someone who learnt without them will also be able
>>>> to do <everything> without them.
>>>
>>> Do you <really> believe on this? ;-)
>>
>> Yes, because it's what I do.
>
> Oh c'mon Arnaud... you're not serious, are you? ;-)
>
> It seems you never had to develop an application that needed to
> store/access/share relational data with millions of records across a
> network with several users or even a web application with similar
> requirements. If you needed that, your best (and probably only)
> solution would be to use database(s), either you like it or not.

Indeed, I had not to do that.

> It's ok if you never had to develop such kind of applications, but as
> a programmer (professional or not) you should refrain yourself from
> making such kind of statements like "and __someone__ who learnt
> without them [databases] will also be able to do __<everything>
> without them__" (__emphasis__ by me) because, in my opinion, you will
> not "fit well in the picture" (I hope the "fit well in the picture"
> makes sense in English... in my language it does) ;-)

I think I understand what you mean by the french language.
I'm not sure how you would say you're a "complete" programmer if you
don't try Mac, on the other hand ;-)

>>> Once you "dominate" the database "beast" I'm sure you'll kick
>>> yourself
>>> for not learning/using it before ;-)
>>
>> The "problem" with me is that I rarely change my mind.
>> Occasionally, if
>> someone hypnotizes me to use them, I'll think of you as the one who
>> suggested me to do so.
>
> I hope you'll "see the light" ;-)

I'll take "light" as in "without sugar" ;-)

>> As for
>> the "practical" part... well, I could not even use it at home (Mac
>> OS 9 days
>> without a default database engine built-in), so it didn't
>> interested me.
>
> But now you have RB with SQLite ;-)
> The docs from RB are very basic and not very helpful with SQL, but
> there are so many resources out there about SQL.... for example this
> one seems ok to start:
> http://www.w3schools.com/SQl/default.asp

I'll keep this message (as I do for all messages anyway) and, if I
decide this unbelievable thing of learning databases ( ;-) ), I'll
try your link.

>> My point is that I don't think a given programmer will use
>> everything in his
>> life of programmer.
>
> Agree...
>
>> For instance, you're not using Macs ;-)
>
> Who told you so?

Perhaps you're kidding... It was you, I think.

> Yes, you're right, and that was an easy decision ;-)
>
> And there's an "historical" reason for not using a Mac: My first steps
> with programming was with a "ZX Spectrum/Sinclair", then IBM
> Mainframes (COBOL/RPG II), then Windows (network admin/some
> VB/MSSQL/etc). Never saw a Mac at that time in the places where I
> worked... maybe because they were not very popular here (Portugal) due
> to hardware and software costs. So, I never had the need of using or
> purchasing a Mac.

Hmm... Seems to be a similar story than me with databases ;-)

> Currently, I'm undecided between *not* purchasing a Mac and upgrading
> to Windows 7... a tough decision ;-)

I see. Then we have both a decision of trying something we don't have
used yet much yet...
So, if you buy a Mac, I learn databases, and if you don't, I don't
(kind of a game to decide me whether I make some efforts or not ;-) ).
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 14.08.09 02:36 (Thu, 13 Aug 2009 21:36:39 -0400)
From: Cameron McCormick
I know its a misnomer, but whenever someone mentions RPG II, I always think
of video games :-)

HTTP Error #402
Gotta get Paid.
-Cameron

On Thu, Aug 13, 2009 at 9:28 PM, Carlos M <<email address removed>> wrote:

> On Thu, Aug 13, 2009 at 10:40 AM, Arnaud Nicolet wrote:
> > Le 13 août 09 à 3:58, Carlos M a écrit:
> >
> >> On Mon, Aug 10, 2009 at 7:04 PM, Arnaud Nicolet wrote:
> >>> I have the impression that most guy who speaks about databases are
> coming
> >>> from windows... Do you have the same feeling?
> >>
> >> Nope... but I'm a Windows user and *only* use databases when I think
> >> is the best solution.
> >
> > Well, you're anyway showing that another windows user uses them ;-)
>
> Yep, among many, many more Mac users in this list that are, from my
> perception, the majority ;-)
>
> >>> and someone who learnt without them will also be able
> >>> to do <everything> without them.
> >>
> >> Do you <really> believe on this? ;-)
> >
> > Yes, because it's what I do.
>
> Oh c'mon Arnaud... you're not serious, are you? ;-)
>
> It seems you never had to develop an application that needed to
> store/access/share relational data with millions of records across a
> network with several users or even a web application with similar
> requirements. If you needed that, your best (and probably only)
> solution would be to use database(s), either you like it or not.
>
> It's ok if you never had to develop such kind of applications, but as
> a programmer (professional or not) you should refrain yourself from
> making such kind of statements like "and __someone__ who learnt
> without them [databases] will also be able to do __<everything>
> without them__" (__emphasis__ by me) because, in my opinion, you will
> not "fit well in the picture" (I hope the "fit well in the picture"
> makes sense in English... in my language it does) ;-)
>
> >> Once you "dominate" the database "beast" I'm sure you'll kick yourself
> >> for not learning/using it before ;-)
> >
> > The "problem" with me is that I rarely change my mind. Occasionally, if
> > someone hypnotizes me to use them, I'll think of you as the one who
> > suggested me to do so.
>
> I hope you'll "see the light" ;-)
>
> > Just note that I have already used and learnt databases (at school). The
> > theoretical part was a nightmare (with very bad notes/points (I don't
> know
> > how you say in english, sorry. I mean the score the teacher gives)).
>
> I see... In my situation I had very good trainers when I took (way
> back) one of my MS certifications that included MSSQL database
> design/implementation/administration and it was easy to learn, study
> and pass the exams. Having also some background with databases and
> loving the subject helped a lot.
>
> > As for
> > the "practical" part... well, I could not even use it at home (Mac OS 9
> days
> > without a default database engine built-in), so it didn't interested me.
>
> But now you have RB with SQLite ;-)
> The docs from RB are very basic and not very helpful with SQL, but
> there are so many resources out there about SQL.... for example this
> one seems ok to start:
> http://www.w3schools.com/SQl/default.asp
>
> > My point is that I don't think a given programmer will use everything in
> his
> > life of programmer.
>
> Agree...
>
> > For instance, you're not using Macs ;-)
>
> Who told you so?
> .
> .
> .
> .
> .
> .
> .
> .
> .
> Yes, you're right, and that was an easy decision ;-)
>
> And there's an "historical" reason for not using a Mac: My first steps
> with programming was with a "ZX Spectrum/Sinclair", then IBM
> Mainframes (COBOL/RPG II), then Windows (network admin/some
> VB/MSSQL/etc). Never saw a Mac at that time in the places where I
> worked... maybe because they were not very popular here (Portugal) due
> to hardware and software costs. So, I never had the need of using or
> purchasing a Mac.
>
> Currently, I'm undecided between *not* purchasing a Mac and upgrading
> to Windows 7... a tough decision ;-)
>
> Carlos
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 14.08.09 02:34 (Thu, 13 Aug 2009 21:34:50 -0400)
From: Cameron McCormick
Um, I donno if you some additional reason for this, but as a windows only
developer, why not use the registry? That's what its there for... It would
avoid the user accidentally deleting the settings. Of course it isn't 100%
foolproof, but the user would have to go out of their way to delete it...

HTTP Error #402
Gotta get Paid.
-Cameron

On Wed, Aug 12, 2009 at 8:54 PM, Carlos M <<email address removed>> wrote:

> On Mon, Aug 10, 2009 at 11:01 AM, Jan-Ivar Mellingen wrote:
> > I am using the built-in RB database for my settings, just containing a
> > simple table. It allows me to easy port my old VB5 code, and at the same
> > time avoid a lot of platform problems.
>
> I'm also using this solution for some apps with good results.
>
> > I have placed the database file in a folder with full user access,
> > avoiding any permission problems. A nice side-effect is that the
> > settings are also copied when the user (hopefully) backs up his
> > documents (home) folder.
>
> I see the advantages in storing the prefs in a folder inside the
> documents folder. But I see a big disadvantage: if the user does not
> recognize the folder or associates the folder to your application,
> he/she might delete it. If I used this approach I would make sure to
> have inside it a text file named something like "DO NOT DELETE THIS
> FOLDER AND FILES - READ ME.txt" and explain what the folder is used
> for... just in case ;-)
>
> Being a Windows only developer, I prefer to store the prefs in the
> user's "Application Data" folder. I'm also implementing a backup
> system in case a prefs file get corrupted and that is to store in a
> "backup" sub-folder a copy of the last saved prefs file and keep only
> there files of the last 30 days or the last 10 files of different
> days. I named them in the format "YYYYMMDDHHMMSS-backup". I'm also
> considering giving an option in the software for the user to store a
> backup of the prefs file in a location they want.
>
> > Other folders may be more suitable for settings common to several users
> > or several applications.
> Yep...
>
> Carlos
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 14.08.09 02:28 (Fri, 14 Aug 2009 02:28:23 +0100)
From: Carlos M
On Thu, Aug 13, 2009 at 10:40 AM, Arnaud Nicolet wrote:
> Le 13 août 09 à 3:58, Carlos M a écrit:
>
>> On Mon, Aug 10, 2009 at 7:04 PM, Arnaud Nicolet wrote:
>>> I have the impression that most guy who speaks about databases are coming
>>> from windows... Do you have the same feeling?
>>
>> Nope... but I'm a Windows user and *only* use databases when I think
>> is the best solution.
>
> Well, you're anyway showing that another windows user uses them ;-)

Yep, among many, many more Mac users in this list that are, from my
perception, the majority ;-)

>>> and someone who learnt without them will also be able
>>> to do <everything> without them.
>>
>> Do you <really> believe on this? ;-)
>
> Yes, because it's what I do.

Oh c'mon Arnaud... you're not serious, are you? ;-)

It seems you never had to develop an application that needed to
store/access/share relational data with millions of records across a
network with several users or even a web application with similar
requirements. If you needed that, your best (and probably only)
solution would be to use database(s), either you like it or not.

It's ok if you never had to develop such kind of applications, but as
a programmer (professional or not) you should refrain yourself from
making such kind of statements like "and __someone__ who learnt
without them [databases] will also be able to do __<everything>
without them__" (__emphasis__ by me) because, in my opinion, you will
not "fit well in the picture" (I hope the "fit well in the picture"
makes sense in English... in my language it does) ;-)

>> Once you "dominate" the database "beast" I'm sure you'll kick yourself
>> for not learning/using it before ;-)
>
> The "problem" with me is that I rarely change my mind. Occasionally, if
> someone hypnotizes me to use them, I'll think of you as the one who
> suggested me to do so.

I hope you'll "see the light" ;-)

> Just note that I have already used and learnt databases (at school). The
> theoretical part was a nightmare (with very bad notes/points (I don't know
> how you say in english, sorry. I mean the score the teacher gives)).

I see... In my situation I had very good trainers when I took (way
back) one of my MS certifications that included MSSQL database
design/implementation/administration and it was easy to learn, study
and pass the exams. Having also some background with databases and
loving the subject helped a lot.

> As for
> the "practical" part... well, I could not even use it at home (Mac OS 9 days
> without a default database engine built-in), so it didn't interested me.

But now you have RB with SQLite ;-)
The docs from RB are very basic and not very helpful with SQL, but
there are so many resources out there about SQL.... for example this
one seems ok to start:
http://www.w3schools.com/SQl/default.asp

> My point is that I don't think a given programmer will use everything in his
> life of programmer.

Agree...

> For instance, you're not using Macs ;-)

Who told you so?
.
.
.
.
.
.
.
.
.
Yes, you're right, and that was an easy decision ;-)

And there's an "historical" reason for not using a Mac: My first steps
with programming was with a "ZX Spectrum/Sinclair", then IBM
Mainframes (COBOL/RPG II), then Windows (network admin/some
VB/MSSQL/etc). Never saw a Mac at that time in the places where I
worked... maybe because they were not very popular here (Portugal) due
to hardware and software costs. So, I never had the need of using or
purchasing a Mac.

Currently, I'm undecided between *not* purchasing a Mac and upgrading
to Windows 7... a tough decision ;-)

Carlos

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 13.08.09 10:40 (Thu, 13 Aug 2009 11:40:40 +0200)
From: Arnaud Nicolet
Le 13 août 09 à 3:58, Carlos M a écrit:

> On Mon, Aug 10, 2009 at 7:04 PM, Arnaud Nicolet wrote:
>> Le 10 août 09 à 16:05, Jan-Ivar Mellingen a écrit:
>>
>>> Anyway, my problem replacing VB's Get/SetSetting was solved this
>>> way.
>>> Cross-platform, no more messing with the Windows Registry, same
>>> logic on
>>> all platforms. Life is easy.
>>
>> I have the impression that most guy who speaks about databases are
>> coming
>> from windows... Do you have the same feeling?
>
> Nope... but I'm a Windows user and *only* use databases when I think
> is the best solution.

Well, you're anyway showing that another windows user uses them ;-)

>>> If you don't like databases, of course a text file with some id/
>>> value
>>> pairs or a xml structure will work just as nicely. I considered
>>> that,
>>> but for my purpose the use of the database file relieved me of
>>> having to
>>> parse the contents myself, simplifiying my code.[...]
>>
>> I think someone who learnt with databases will always find a way
>> to do
>> <everything> with them
>
> Maybe, but databases are not the solution for <everything>!

Here' I trust you ;-)

>> and someone who learnt without them will also be able
>> to do <everything> without them.
>
> Do you <really> believe on this? ;-)

Yes, because it's what I do.

> Anyway Arnaud, I'm aware that you don't like databases... but you
> should really try because they are very very useful. For example, the
> use of In-Memory databases are so useful that you might don't know
> what you're missing - instead of using complex data structures with
> dictionaries/classes/arrays, sometimes the use of an [optimized]
> In-Memory database is not only faster but also simpler.
>
> Once you "dominate" the database "beast" I'm sure you'll kick yourself
> for not learning/using it before ;-)

The "problem" with me is that I rarely change my mind. Occasionally,
if someone hypnotizes me to use them, I'll think of you as the one
who suggested me to do so.
Just note that I have already used and learnt databases (at school).
The theoretical part was a nightmare (with very bad notes/points (I
don't know how you say in english, sorry. I mean the score the
teacher gives)). As for the "practical" part... well, I could not
even use it at home (Mac OS 9 days without a default database engine
built-in), so it didn't interested me.

My point is that I don't think a given programmer will use everything
in his life of programmer. For instance, you're not using Macs ;-)
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 13.08.09 02:58 (Thu, 13 Aug 2009 02:58:16 +0100)
From: Carlos M
On Mon, Aug 10, 2009 at 7:04 PM, Arnaud Nicolet wrote:
> Le 10 août 09 à 16:05, Jan-Ivar Mellingen a écrit:
>
>> Anyway, my problem replacing VB's Get/SetSetting was solved this way.
>> Cross-platform, no more messing with the Windows Registry, same logic on
>> all platforms. Life is easy.
>
> I have the impression that most guy who speaks about databases are coming
> from windows... Do you have the same feeling?

Nope... but I'm a Windows user and *only* use databases when I think
is the best solution.

>> If you don't like databases, of course a text file with some id/value
>> pairs or a xml structure will work just as nicely. I considered that,
>> but for my purpose the use of the database file relieved me of having to
>> parse the contents myself, simplifiying my code.[...]
>
> I think someone who learnt with databases will always find a way to do
> <everything> with them

Maybe, but databases are not the solution for <everything>!

> and someone who learnt without them will also be able
> to do <everything> without them.

Do you <really> believe on this? ;-)

---

Anyway Arnaud, I'm aware that you don't like databases... but you
should really try because they are very very useful. For example, the
use of In-Memory databases are so useful that you might don't know
what you're missing - instead of using complex data structures with
dictionaries/classes/arrays, sometimes the use of an [optimized]
In-Memory database is not only faster but also simpler.

Once you "dominate" the database "beast" I'm sure you'll kick yourself
for not learning/using it before ;-)

Carlos

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 13.08.09 01:54 (Thu, 13 Aug 2009 01:54:53 +0100)
From: Carlos M
On Mon, Aug 10, 2009 at 11:01 AM, Jan-Ivar Mellingen wrote:
> I am using the built-in RB database for my settings, just containing a
> simple table. It allows me to easy port my old VB5 code, and at the same
> time avoid a lot of platform problems.

I'm also using this solution for some apps with good results.

> I have placed the database file in a folder with full user access,
> avoiding any permission problems. A nice side-effect is that the
> settings are also copied when the user (hopefully) backs up his
> documents (home) folder.

I see the advantages in storing the prefs in a folder inside the
documents folder. But I see a big disadvantage: if the user does not
recognize the folder or associates the folder to your application,
he/she might delete it. If I used this approach I would make sure to
have inside it a text file named something like "DO NOT DELETE THIS
FOLDER AND FILES - READ ME.txt" and explain what the folder is used
for... just in case ;-)

Being a Windows only developer, I prefer to store the prefs in the
user's "Application Data" folder. I'm also implementing a backup
system in case a prefs file get corrupted and that is to store in a
"backup" sub-folder a copy of the last saved prefs file and keep only
there files of the last 30 days or the last 10 files of different
days. I named them in the format "YYYYMMDDHHMMSS-backup". I'm also
considering giving an option in the software for the user to store a
backup of the prefs file in a location they want.

> Other folders may be more suitable for settings common to several users
> or several applications.
Yep...

Carlos

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 13.08.09 08:42 (Thu, 13 Aug 2009 09:42:01 +0200)
From: Jan-Ivar Mellingen


Carlos M skrev:
> On Mon, Aug 10, 2009 at 11:01 AM, Jan-Ivar Mellingen wrote:
>
>> I am using the built-in RB database for my settings, just containing a
>> simple table. It allows me to easy port my old VB5 code, and at the same
>> time avoid a lot of platform problems.
>>
> I'm also using this solution for some apps with good results.
>
>> I have placed the database file in a folder with full user access,
>> avoiding any permission problems. A nice side-effect is that the
>> settings are also copied when the user (hopefully) backs up his
>> documents (home) folder.
>>
> I see the advantages in storing the prefs in a folder inside the
> documents folder. But I see a big disadvantage: if the user does not
> recognize the folder or associates the folder to your application,
> he/she might delete it. If I used this approach I would make sure to
> have inside it a text file named something like "DO NOT DELETE THIS
> FOLDER AND FILES - READ ME.txt" and explain what the folder is used
> for... just in case ;-)
>
> Being a Windows only developer, I prefer to store the prefs in the
> user's "Application Data" folder. I'm also implementing a backup
> system in case a prefs file get corrupted and that is to store in a
> "backup" sub-folder a copy of the last saved prefs file and keep only
> there files of the last 30 days or the last 10 files of different
> days. I named them in the format "YYYYMMDDHHMMSS-backup". I'm also
> considering giving an option in the software for the user to store a
> backup of the prefs file in a location they want.
>
>> Other folders may be more suitable for settings common to several users
>> or several applications.
>>
> Yep...Carlos
>
The 'best' location has been discussed a lot on this forum. Ideally the
RB 'Special' folders should, in my opinion, automatically select the
most appropritate location for each OS, but unfortunately this is not so.
Besides, what may be the best location on one OS may be a bad choice on
another OS, and different applications may dictate varying choices. Also
the users behaviour may vary a lot (to say it mildly). I can understand
why RS has left the choice to us...

/Jan-Ivar

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Storing Application Settings
Date: 11.08.09 14:17 (Tue, 11 Aug 2009 15:17:48 +0200)
From: Arnaud Nicolet
Le 11 août 09 à 14:47, Jan-Ivar Mellingen a écrit:

> Arnaud Nicolet skrev:
>> I have the impression that most guy who speaks about databases are
>> coming from windows... Do you have the same feeling?
> Speaking for myself, I have been developing software for more than 40
> years, but not always on Windows. Windows was invented after my first
> commercial Alarm Receiving Centre database application: coded in BBC
> Basic, running on the BBC computer with plenty of RAM (64KB) and huge
> disks (2x400KB floppy).
> Later I ported to DOS with Btrieve database (then Novell, now it is
> called Pervasive SQL). I also had a short sidetrack on CP/M.
> After some years coding in Modula-2 for DOS/Windows I was planning to
> port to OS/2. Actually the plan was to use Visual Basic to make
> cross-platform Windows / OS/2 applications. After I was finished
> porting
> my code to VB, Microsoft dropped OS/2 support in VB, then OS/2 died...
> This first application is still being developed in accordance with
> customer needs and technological change. Most of the present code is
> still in VB5 (Windows only), and the database is now PostgreSQL (on
> Linux or Windows). The data volume has grown in theese 40+ years from
> 200KB to 200GB...
> These days we are trying to get rid of the extremely troublesome and
> instable OS called Windows and are aiming at Linux, replacing VB
> with RB
> but keeping the PostgreSQL database (the best there is, in my
> opinion).
> So far it looks good, everyting I have developed on Windows also
> runs on
> Linux without any work on my part. Just compile and run!
>> I think someone who learnt with databases will always find a way
>> to do
>> <everything> with them and someone who learnt without them will also
>> be able to do <everything> without them.
> In the 40+ years I have been coding I have used first .ini files and
> later the Windows Registry for keeping settings etc. Lately I have
> gone
> back to .ini files as it gives me more control and easier support. The
> Registry is not well suited for my purpose, certainly if you have to
> guide the user in order to change some obscure settings. In the
> process
> of moving to a cross-platform environment I discovered the SQLite (RB
> database) which simplified things a lot. Now we use a free SQLite
> browser to change the settings, if necessary. Easier than using a text
> editor on a text file...
> So, I am not used to do 'everyting' with a database. Large
> databases are
> are for managing huge amounts of data!
> - But the local, tiny, single-file database has its benefits. I could
> certainly find more uses for it...

Thanks. An interesting story.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>