[.NET / Windows Forms] Opslaan gebruikers configuratie

[Verwijderd]

Beste mede Tweakers,

Ik heb een vraag m.b.t. opslaan van gebruikers configuratie/instellingen in een Windows Forms Applicatie

Ik heb tot nu toe altijd veel met asp.net gedaan en daar vond ik het makkelijk om gebruikers instellingen/configuratue in SQL op te slaan in een Database of Table.Het gaat zich erom dat gebruikers instellingen m.b.t. aanvinken van hokjes, invullen van gewenste gegevens in een DropDownList etc.

Onthouden worden en bij de volgende keer bij het opstarten van de Applicatie deze hier nog steeds staan.

Nou kan dit in een XML of .MDB bestand of Settings.Setting. maar ik vroeg me af wat hier het makkelijkste en beste voor is?

Ik weet dit kan overkomen als een erg open vraag, maar ik wil graag weten hoe mensen die veel met Windows Forms werken hun gebruikers configuratie opslaan, zodat deze ook bij het afsluiten van de Applicatie onthouden wordt en hoe deze makkelijk te bewerken is.

Alvast bedankt,

Vincent

[Kalentum]

Als gebruiker heb ik een voorkeur voor tekstfiles (bv ini-files). Die kun je makkelijk kopieren en bewerken buiten je programma om.

Het makkelijkste is de Registry.

Een database lijkt me wat overkill voor configuratiesettings.

[Sebazzz]

Je kan het via een .settings file doen, via INI (dit vind ik prettig bij simpele instellingen / simpele programma's) of je kan zelf een klasse schrijven die de instellingen beheert en het dan binair of geserialized naar XML wegschrijven. Dit laatste doe ik. Of als laatste optie kan je ook nog overwegen om SQLite te gebruiken, database in één bestand waar je geen server voor nodig hebt. Alleen maar msvcrt en sqlite3.dll

[Danot]

Ik raad je aan om .settings te gebruiken. Ini files zijn verouderd en een database is overkill voor wat simpele settings. Meer info vind je hier: http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

[Razr]

Ik raad je ook aan om settings te gebruiken, het werkt erg prettig en fijn. Je kunt in het configuratie scherm van je applicatie aangeven welke velden je wilt gaan gebruiken en deze kun je vervolgens simpel aanroepen:

C#:

txtVeldA.Text = Settings.Default.WaardeA;

En om te wijzigen:

C#:

Settings.Default.WaardeA = "EenWaarde";

Vergeet niet om je settings op te slaan nadat je een andere waarde hebt toegewezen:

C#:

Settings.Default.Save();

Of je maakt een event welke elke keer nadat een setting is gewijzigd zelf de Save() methode aanroept.

[ Voor 7% gewijzigd door Razr op 15-11-2008 12:37 ]

[whoami]

rutgerw schreef op zaterdag 15 november 2008 @ 11:10:
Als gebruiker heb ik een voorkeur voor tekstfiles (bv ini-files). Die kun je makkelijk kopieren en bewerken buiten je programma om.

Het makkelijkste is de Registry.

Een database lijkt me wat overkill voor configuratiesettings.

ini files om je user settings in op te slaan is -zoals hier reeds aangehaald- verouderd. Je kan bv je settings bv in XML files gaan opslaan, en deze in de LocalSettings folder bv gaan opslaan.
Je kan ook gebruik gaan maken van de settings-infrastructuur die .NET al voorziet.

user settings opslaan in de registry is al helemaal geen goed idee; niet iedereen heeft nl. rechten om in de registry te gaan schrijven.

[Verwijderd]

Bedankt voor jullie reacties,

Ik denk dat ik het hou bij setting.Settings heb er wat meer over gelezen en snel wat geprobeerd en dit werkt echt ideaal met wat ik in gedachte had.

Topic mag dicht wat mijn bedreft

Vincent

[Verwijderd]

Settings is idd erg handig en snel te implementeren, en wanneer 't geen probleem is dat de settings locaal worden opgeslagen gaat 't prima werken.
Maar wanneer je gebruikers gebruik maken van een connectie op een Terminal Server park (gisteren TS1, vandaag toevallig TS2) en je ook machine-specifieke settings op wil slaan (op deze TS is de default factuurprinter Printer1) dan is m.i. opslaan in een centrale database een stuk handiger. Idem met roaming profiles.
Bij roaming profiles kun je de .settings file wel meenemen, maar als opeens de factuurprinter 4 blokken verderop staat (of in een ander continent) dan is dat niet handig...

[CMG]

whoami schreef op zaterdag 15 november 2008 @ 12:51:
[...]

ini files om je user settings in op te slaan is -zoals hier reeds aangehaald- verouderd. Je kan bv je settings bv in XML files gaan opslaan, en deze in de LocalSettings folder bv gaan opslaan.
Je kan ook gebruik gaan maken van de settings-infrastructuur die .NET al voorziet.

user settings opslaan in de registry is al helemaal geen goed idee; niet iedereen heeft nl. rechten om in de registry te gaan schrijven.

Het kan makkelijker met .NET.

Maak een class waarin je alle settings voor een user opslaat. Gebruik dit altijd als container bij het lezen/schrijven van waardes. Bij het afsluiten van het programma doe je een Binary Serialize naar disk, bij het starten van de app DeSerialize je het bestand en heb je meteen alles als een .NET object. Geen eigen parser, settings uitbreiden is gewoon een extra variable in je structure/class toevoegen en voor de rest hoef je niets aan te passen.

[Aphelion]

Als aanvulling op CMG:
Wat je ook kan doen is een eigen 'class' die de settings bewaart en dit door middel van serializen in XML op
te slaan zonder dat je je hoeft druk te maken over de 'structuur' en het lezen/schrijven van je XML.

Het voordeel van XML t.o.v. binary is dat je toch een leesbare configuratiefile hebt.

[Verwijderd]

Naar CMG en Aphelion zou ik niet luisteren, die proberen beiden onderstaand wiel opnieuw uit te vinden:

Danot schreef op zaterdag 15 november 2008 @ 11:37:
Ik raad je aan om .settings te gebruiken. Ini files zijn verouderd en een database is overkill voor wat simpele settings. Meer info vind je hier: http://msdn.microsoft.com/en-us/library/aa730869(VS.80).aspx

Gewoon lekker gebruiken wat het framework je aanbiedt .

[farlane]

En toen wilde je applicatie wide settings gaan opslaan, die met de settings API read only zijn. *zucht*

[Aphelion]

Verwijderd schreef op zondag 16 november 2008 @ 13:50:
Naar CMG en Aphelion zou ik niet luisteren, die proberen beiden onderstaand wiel opnieuw uit te vinden:


[...]


Gewoon lekker gebruiken wat het framework je aanbiedt .

Hoezo het wiel opnieuw uit te vinden? Als je meer wilt, of op begeven moment de overhead van het ingebouwde systeem niet meer wilt hebben, dan heb je er uit eindelijk meer werk aan.

Overigens is het serializen van een klass 2 regels code. Je moet ook de doestelling van 'de gebruiker moet gemakkelijk een config file kunnen editen' niet vergeten. De gebruiker heeft in dat geval ook geen besef van machine/app scopes.

/edit:

Ik quote:

Objects serialized by using XML can be viewed and edited by using any text editor, including Notepad. If you are storing objects in files, this gives administrators the opportunity to view and edit the XML file. This can be useful for customizing your application, troubleshooting problems, and developing new applications that interoperate with your existing application.

[ Voor 21% gewijzigd door Aphelion op 21-11-2008 11:32 . Reden: Onderbouwing ]