On 12/19/2018 23:01, Chris Locke wrote:
What application are you using to build your application?  You mentioned
Visual Studio, so .NET?  If so, are you using the SQLite library from
system.data.sqlite.org?  Are you using c# or vb?

   Yes.  .NET via vb using wpf.
   I plan to use the library.  Right now I'm in the contemplation
   stage.  :-)  Once I
   settle on my approach to this issue, I'll start the coding.


My settings table is a lot simpler.  id, setting and value.  3 columns.
Possibly 4, adding a 'code' column. The 'setting' column holds the full
setting you want to store, eg, 'main form height', or 'main form
windowstate'.  I can have user settings in this via 'chris/main form
height'.  I can then store that setting name as a constant in my
application, so its accessible via Intellisense.  Doing a series of quick
database lookups is relatively cheap.  You can also group the settings if
need be, so 'main form/height' and 'main form/windowstate' so you could
pull out a group of settings with one database query.
Happy to link you to a sample if needed.  A simple (although bloaty!)
database class can be used for the mundane database work - reading,
creating, editing and deleting records.  I tend to ensure my databases have
unique rowIds, and use these for the glue for relationships.

   Hey, you're ahead of me so let me ask for a few more details.  I
   contemplate bringing
   the data from the db into a class for each window that I can bind
   the values to.  That way
   the only other code necessary is to push altered any values back to
   the db when the window
   closes.  In your setup, then, how do you tell the "main form" that
   the binding is on the
   height property.  Or do you just assign the value in the loaded
   event and keep track of
   changes in your own code?

   Thanks a lot for your time; I'm stretching to put this together ...
   which is part of the fun.

Thanks,
Chris

On Thu, Dec 20, 2018 at 3:37 AM Roger Schlueter <se...@cox.net> wrote:

On 12/19/2018 10:02, Jens Alfke wrote:
On Dec 18, 2018, at 7:46 PM, Roger Schlueter <se...@cox.net> wrote:

I am starting work on a prototype application so this might be an
excellent opportunity to use SQLite for my application file format.  Part
of this would be the saving and restoring of GUI elements such as window
positions and sizes, control states, themes, etc.
IMHO something like JSON is a good format for such config/preference
data, instead of having a table with a column for every pref. During
development you’ll often be adding new prefs, and it’s a pain to have to
update a CREATE TABLE statement every time you add one. It’s even more of a
pain to have to handle a schema change with ALTER TABLE in an app upgrade
that adds a new pref. If you use JSON you just have to come up with a new
string to use as the key for each pref. It’s also easy to have structured
values like arrays or nested objects. (FWIW, his is essentially the way
that Apple OS’s manage app prefs via the NSUserDefaults class.)

     JSON or XML: Two sides of the same coin.  If I wanted to go the
     separate file approach, I'd just use the settings class of Visual
     Studio since all the required plumbing is already in place.

     More importantly, as I noted this is a prototype (read: test)
     application so it is a good opportunity for me to get my feet wet
     with SQLite since I'm a n00b with it.

Of course you can save the JSON in the database file. Just create a
‘prefs’ table with one blob column for the JSON.
A related solution is to store each named pref as a row in the ‘prefs’
table, identified by a ‘key’ column.

     In fact, this statement makes the concerns you raised in the first
     paragraph moot.  A simple table with four columns:

      1. Window name
      2. Control name
      3. Control property
      4. Property value

     covers all the possibilities, no ALTER table necessary.  If I want
     to enable per user values, I'd just add a User column.

In short, the design part is easy IMO.  I'm still hoping to see some
examples since, surely, I'm not the first person to go this route.
—Jens
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to