[C++] beste plaats om 'settings' te bewaren bij gebruiker

[Verwijderd]

Dag allemaal,

Ben een toepassingetje aan't maken waarbij de gebruiker enkele opties ter beschikking heeft. Deze post gaat over mogelijkheden om die instellingen te bewaren en iets concreter, een stap richting uitwerking.

Voorlopig zit ik aan twaalf booleans aan informatie (dit geheel terzijde).

Wat meer over taal enz., maar laat u dat niet afschrikken. 't zou hier net zo goed over andere talen kunnen gaan. Ik maak de toepassing in M$Microsoft Visual C++ en ik maak gebruik van de MFC (dus Windows). Voor diegenen die dat niet kennen: dat is nog een extra laag, bovenop wat je kan gebruiken bij een 'gewoon' VC++ project, die ontwikkeld is door M$Microsoft met als doel de WinAPI objectgeoriënteerd te kunnen gebruiken (de API is dus ingedeeld in klassen).

1) 't register.
Liefst zou ik de data opslaan in het register (-> geen geknoei met bestanden). Ik zie dat op mijn OS de informatie die programma's opslaan staat in HKEY_CURRENT_USER\Software\mijnToepassing. Is dat officieel (= voor alle Windowsen), of moet ik voor elke windows-versie nog iets anders doen; of is het afhankelijk van nog iets anders? Want ik zie dat vele programma's op veel plaatsen in't register vanalles zetten.

2) zo'n ini-bestand
veel opties, en ook vaak van Windows zelf, wordt opgeslagen in .ini-bestanden met zo'n typische syntax. Is dat op een of andere manier standaard, en dus gemakkelijk te implementeren in mijn programma? Of is dat prehistorisch en niet gemakkelijker?

3) een ander bestand
zijn er ook degelijke toepassingen die zo'n data gewoon opslaan in een zelf aangemaakt bestand? worden die dan gecodeerd, zodat een gebruiker daar niet mee kan prutsen (en bvb de data ongeldig maakt) ?

Alvast bedankt.

Modbreak:

M$ is een kinderachtige verbastering van Microsoft. Noem het bedrijf gewoon normaal bij z'n naam, of kort het af met MS. In je vorige post heb ik dat ook al gezegd; volgende keer worden er andere maatregelen genomen.

[ Voor 11% gewijzigd door gorgi_19 op 10-09-2004 11:45 ]

[pjvandesande]

Liever geen verbasteringen gebruiken als m$.

Hier zijn gewoon richtlijnen voor. Gebruiker afhankelijke settings in register of bij XP zijn hier al speciale mappen voor. Kijk hier is naar.

[Skaah]

c:\Documents & Settings\username\Application Data\

Kijk daar maar eens.

[pjvandesande]

Skaah schreef op 10 september 2004 @ 11:47:
c:\Documents & Settings\username\Application Data\

Kijk daar maar eens.

Die bedoelde ik idd. Er is een heel artikel over, het staat beschreven in het artikel over 'MS Windows Game' oid, ik kan hem zo even niet vinden. Maar zoek wel even thuis, eerst even werken

[ Voor 3% gewijzigd door pjvandesande op 10-09-2004 11:51 ]

[Verwijderd]

Niets zo vervelend aan windows is dat de settings overal staan: register, .ini in directory van applicatie, .ini in windows\system, \Application Data, \My Documents, ...

Mijn voorkeur gaat uit naar een simpel XML-bestandje, dat je bewaart in de applicatie-directory.

Als de gebruiker bijv. wilt formatteren, moet hij gewoon dat ene filetje backuppen.

tip: zorg ervoor dat settings-bestanden altijd 'blijven werken', zelfs 10 versies van de applicatie later. Het is niet fijn dat je een backup maakt van je settings, formatteert, de applicatie opnieuw installeert, en dan moet vastellen dat je backup niet meer bruikbaar is, omdat je voor de format een oudere versie gebruikte.

[pjvandesande]

questa schreef op 10 september 2004 @ 11:51:
Die bedoelde ik idd. Er is een heel artikel over, het staat beschreven in het artikel over 'MS Windows Game' oid, ik kan hem zo even niet vinden. Maar zoek wel even thuis, eerst even werken

toch maar even opgezocht:
Games for Microsoft Windows

Hier staat ergens een stuk over setting.

quote: http://msdn.microsoft.com...rame=true#gamessf1_topic3

3.0 Data and Settings Management: Requirements Summary
Windows XP provides an infrastructure that supports state separation of user data, user settings, and computer settings. Applications that use this infrastructure correctly offer the following benefits:

Applications do not fail when run by Limited Users (non-Administrator), allowing family or friends to share a computer safely and easily.
Parents can allow children to use the computer without giving them administrative privileges, which would give the child unrestricted access to modify the computer.
Users can back up their individual documents and settings easily without needing to back up application and operating system files.
Multiple users can share a single computer, each with their own preferences and settings.
Applications are less likely to prevent Fast User Switching from operating correctly and efficiently.

[ Voor 51% gewijzigd door pjvandesande op 10-09-2004 12:08 ]

[BurningSheep]

Verwijderd schreef op 10 september 2004 @ 11:57:
Als de gebruiker bijv. wilt formatteren, moet hij gewoon dat ene filetje backuppen.

Een filetje per applicatie! De gemiddelde gebruiker gebruikt natuurlijk meerdere applicaties. En precies daarom zijn er door Microsoft standaarden in het leven geroepen zoals bijvoorbeeld de Application Data folder.

Dat het in de praktijk niet echt lijkt te werken komt omdat veel developers toch liever hun eigen standaarden erop na houden, wat op zich een beetje jammer is. Toch is dit grotendeels Microsofts eigen schuld omdat ze niet van het begin af aan een duidelijke lijn hierin hebben gevolgd.

[farlane]

Gewoon een ini/xml/whatever bestand in de applicatie dir pleuren ( of ergens in de tree eronder ). Is eigenlijk gewoon een applicatieregister, in de applicatiedir )

- Het register een slecht idee was dat slecht is uitgevoerd. ( Bloat, Bloat, Bloat en nog eens bloat. )
- Die standaard ( als je daarvan kunt spreken ) plaatsen die ervoor gemaakt zijn, zijn ook een slecht idee. Ik wil mijn systeem, applicaties en data op aparte partities hebben. Meuk opslaan in een dir die zonder verschrikkelijk veel moeite niet te verplaatsen is is een slecht idee )( Bloat bloat en nog eens bloat ).
-
Een applicatie kunnen installeren door het simpelweg te kopieren ( ging MS daar ook niet naar terug met .NET? ) is gewoon top. Geen meuk die achterblijft, een deltree en alle rotzooi is pleite.
Je ini file coderen kan op 1000 verschillende manieren( Maar de vraag is of je dat wel wil. ) Je moet er gewoon altijd voor zorgen dat als het formaat niet goed is door gerommel van de gebruiker, dat je je default waardes neemt en die opslaat. Dat geldt voor de andere methoden ook )

Voor het schrijven van ini bestanden zijn btw een aantal API functie beschikbaar ( WritePrivateProfileXXXX )

[ Voor 7% gewijzigd door farlane op 10-09-2004 12:27 ]

[curry684]

BurningSheep schreef op 10 september 2004 @ 12:08:
[...]

Dat het in de praktijk niet echt lijkt te werken komt omdat veel developers toch liever hun eigen standaarden erop na houden, wat op zich een beetje jammer is. Toch is dit grotendeels Microsofts eigen schuld omdat ze niet van het begin af aan een duidelijke lijn hierin hebben gevolgd.

Microsoft heeft al sinds 1995 een duidelijke lijn, en hij heet Registry Ik ben het er overigens direct mee eens dat dat niet altijd de optimale oplossing is

Later zijn daar Application Data en Global Application Data aan toegevoegd toen applicaties begonnen met binary blobs van soms megabytes groot in de registry te pleuren

[Verwijderd]

En mischien wil je ook rekening houden met meerdere gebruikers op 1 PC. Daar komt ook bij dat gebruikers die geen administror rechten hebben niet in de program files/appdir mogen schrijven. Ik zou gaan voor %appdata%.

[curry684]

Verwijderd schreef op 10 september 2004 @ 12:43:
Ik zou gaan voor %appdata%.

Voor SHGetFolderPath(CSIDL_APPDATA) hoop ik dan toch

[.oisyn]

farlane schreef op 10 september 2004 @ 12:23:
Gewoon een ini/xml/whatever bestand in de applicatie dir pleuren ( of ergens in de tree eronder ). Is eigenlijk gewoon een applicatieregister, in de applicatiedir )

Ja fijn, elke user dezelfde settings
Er is niet voor niets een verschillende HKEY_CURRENT_USER en Appdata dir voor elke user op het systeem.

- Het register een slecht idee was dat slecht is uitgevoerd. ( Bloat, Bloat, Bloat en nog eens bloat. )

Dit vind ik een beetje onzin. Het registry is niet bloated, er staat gewoon veel in. Er is dan ook veel info om op te slaan. Heb je de linux config files weleens gezien? Die staan helemaal overal en nergens, in windows staan ze tenminste allemaal op dezelfde plek

[schoene]

.oisyn schreef op 10 september 2004 @ 13:44:
[...]


Ja fijn, elke user dezelfde settings
Er is niet voor niets een verschillende HKEY_CURRENT_USER en Appdata dir voor elke user op het systeem.

Maar wat als een programma dezelfde settings moet gebruiken voor verschillende gebruikers. Mij lijkt de current working directory de beste locatie. De gebruiker kiest dan zelf waar de settings moeten opgeslaan worden. Iedere gebruiker kan zn eigen settings hebben, maar de instellingen kunnen ook gedeeld worden

[Robtimus]

.oisyn schreef op 10 september 2004 @ 13:44:
Dit vind ik een beetje onzin. Het registry is niet bloated, er staat gewoon veel in. Er is dan ook veel info om op te slaan.

Vooral fijn dat een groot gedeelte er dubbel instaat, zoals filetypes. Dat hele deel staak zowel in HKCU als in HKLM.

Heb je de linux config files weleens gezien? Die staan helemaal overal en nergens, in windows staan ze tenminste allemaal op dezelfde plek

/etc, /usr/etc, /usr/local/etc, /opt/etc en $HOME. Daarin staan ze of in $HOME zelf als .<programmanaam>[rc], of in een directory .<programmanaam>

Hoezo lastig? Vooral aangezien meestal alleen /etc en /usr/local/etc of /opt/etc worden gebruikt, heb je 2 standaardplekken en de user dir. Net zoals bij Windows dus (HKLM, C:\Windows / C:\WinNT en C:\Documents and Settings\<user>\Application Data)

[pjvandesande]

schoene schreef op 10 september 2004 @ 13:50:
[...]
Maar wat als een programma dezelfde settings moet gebruiken voor verschillende gebruikers. Mij lijkt de current working directory de beste locatie. De gebruiker kiest dan zelf waar de settings moeten opgeslaan worden. Iedere gebruiker kan zn eigen settings hebben, maar de instellingen kunnen ook gedeeld worden

Kun je toch beter settings copieren?

[schoene]

questa schreef op 10 september 2004 @ 13:52:
Kun je toch beter settings copieren?

dan moet je iedere keer voor je het programma opstart de settings copieren, omdat mogelijks een andere gebruiker er ook aan gewerkt heeft? lijkt me niet zo ideaal.

Het grote nadeel is natuurlijk wel dat de gebruiker verantwoordelijk wordt voor het beheer van de instellingen. Dus de gebruiker moet wel weten wat de current working directory is. Voor 'supernoob-applicaties' kan je dit beter niet toepassen

[ Voor 29% gewijzigd door schoene op 10-09-2004 13:58 ]

[curry684]

schoene schreef op 10 september 2004 @ 13:50:
[...]


Maar wat als een programma dezelfde settings moet gebruiken voor verschillende gebruikers.

Dan gebruik je in plaats van HKEY_CURRENT_USER gewoon HKEY_LOCAL_MACHINE zoals het hoort, of in plaats van CSIDL_APPDATA dus CSIDL_COMMON_APPDATA. Ze bedenken die dingen niet voor niets

[.oisyn]

En dus maak je dan een interface in je programma om settings globaal te wijzigen (HKEY_LOCAL_MACHINE), of alleen voor de huidige user (HKEY_CURRENT_USER)

.edit: damn you curry

[ Voor 9% gewijzigd door .oisyn op 10-09-2004 13:57 ]

[schoene]

stel je hebt 7 gebruikers.

gebruiker 1 en 2 werken samen. gebruiker 3, 4 en 5 werken samen, en gebruiker 6 en 7 ook.

wat nu? 3 verschillende user accounts maken?

en hebben gewone gebruikers toegang tot het LOCAL_MACHINE gedeelte?

[ Voor 18% gewijzigd door schoene op 10-09-2004 14:01 ]

[.oisyn]

IceManX schreef op 10 september 2004 @ 13:51:
[...]
Vooral fijn dat een groot gedeelte er dubbel instaat, zoals filetypes. Dat hele deel staak zowel in HKCU als in HKLM.

Duh, iedere user mag z'n eigen filetypes registreren. Ik snap overigens niet wat dit met de strekking van deze topic te maken heeft

/etc, /usr/etc, /usr/local/etc, /opt/etc en $HOME. Daarin staan ze of in $HOME zelf als .[rc], of in een directory .

En in windows heb je dus het registry, appdata en je home dir. Toch weer 1 minder (en nee, ini files in je windows of system dir pleuren is pre-win95 en zou niet meer moeten gebeuren). Overigens ben ik niet zo ervaren in linux, maar ik kon me herinneren dat ik op 100 verschillende plaatsen moest kijken als ik moest zoeken naar een specifieke configfile. Kan best zijn dat ik ernaast zit hoor, maar goed, ook dit is een beetje offtopic

[pjvandesande]

schoene schreef op 10 september 2004 @ 13:54:
[...]


dan moet je iedere keer voor je het programma opstart de settings copieren, omdat mogelijks een andere gebruiker er ook aan gewerkt heeft? lijkt me niet zo ideaal.

Nee, ik praat wel over ieder apparte settings en file, maar ik quote toch:

Maar wat als een programma dezelfde settings moet gebruiken voor verschillende gebruikers

[MBV]

@choene: dan moet je dat zelf verzinnen met je windowsinstallatie. Het effect is dat, ook al werken mensen samen, ze toch hun eigen instellingen willen hebben. Jij wilt window x links hebben, en je collega waarmee je samenwerkt rechts.

Oftewel: luister maar naar ome curry en .oisyn

[Verwijderd]

De feitelijke nadelen van één centraal registry-bestand zijn eigenlijk al opgenoemd met: "alles opslaan in een centraal bestand". Om de zelfde redenen dat je niet alle tables in een database pleurt maar alleen tables die een relatie hebben, zou dat ook met registry settings moeten gebeuren. Nu worden applicaties die totaal los staan van elkaar direct of indirect gehinderd door hun settings in de registry:

1) De registry wordt groter bij (bijna) elke applicatie die je toevoegt, hoe groter de registry hoe trager het doorzoeken/wijzigen van settings.
2) Een applicatie kan het voor alle anderen verzieken door de registry kapot te maken of totaal vol te schrijven met meuk.
3) Door de structuur van de registry (ongerelateerde data in een db) is het vaak lastig om registry settings compleet te verwijderen, hetgeen ook registry bloat oplevert.

[Soultaker]

Verwijderd schreef op 10 september 2004 @ 14:17:
1) De registry wordt groter bij (bijna) elke applicatie die je toevoegt, hoe groter de registry hoe trager het doorzoeken/wijzigen van settings.

Dat is inherent aan het hebben van meer entries in de registry database. Als je veel losse bestanden maakt, duurt het doorzoeken van al die bestanden ook langer dan het doorzoeken van weinig losse bestanden. Meer entries is meer entries, of je die nu in één conceptuele database stopt of in verschillende aparte.

2) Een applicatie kan het voor alle anderen verzieken door de registry kapot te maken of totaal vol te schrijven met meuk.

Dat is een kwestie van rechtenbeheer. Windows NT en verder bieden daar ondersteuning voor. Ik heb er zelf nooit mee gewerkt dus ik kan moelijk zeggen of die mogelijkheden adequaat zijn, maar het is hoe dan ook geen probleem met het hebben van een grote database. Een gewone applicatie kan ook onbeschermde bestanden van andere applicaties wijzigen of verwijderen, of de harde schijf volschrijven.

(Ik heb trouwens nog nooit een applicatie gezien die iets doet met rechtenbeheer in de registry; blijkbaar vindt men het niet zo belangrijk en om eerlijk te zijn: in de praktijk gaat het eigenlijk nooit fout, terwijl de registry toch een aardig doelwit is voor kwaadwillende virussen.)

3) Door de structuur van de registry (ongerelateerde data in een db) is het vaak lastig om registry settings compleet te verwijderen, hetgeen ook registry bloat oplevert.

Ik geef toe dat het vaak wat ondoorzichtig is waar bepaalde instellingen staan. Dat probleem hou je toch, ben ik bang. Voor gewone eindgebruikers moet een installer gewoon bijhouden welke instellingen waar zijn aangepast; daar hoeft de gebruiker zich dan geen zorgen over te maken.

In de praktijk vind ik dat installers/uninstallers onder Windows veel beter met instellingen kunnen werken dan menig ander systeem onder alternatieve besturingssystemen dat met platte configuratiebestanden werkt. Het kost de grootste moeite om op betrouwbare wijze regels toe te voegen aan dit soort ongestructureerde configuratiebestanden en bij het verwijderen van de software de instellingen weer te verwijderen.

[ Voor 8% gewijzigd door Soultaker op 10-09-2004 14:40 ]

[jos707]

Waneer je dus verchillende gebruikers hebt waarvan een aantal settings moeten worden bijgehouden (al dan niet met beveiligingen) dan zou je misschien kunnen opteren voor een database. Dan staat de data ook centraal en is gemakkelijk te backupen, ik denk dat je user - management er alleen maar gemakkelijk op wordt.
Het register zou ik nooit gebruiken want inderdaad wat doe je wanneer de hd wordt geformateerd ? Een database is gewoon veel gemakkelijker om mee te nemen naar een nieuwe pc bijvoorbeeld.

[Soultaker]

jos707 schreef op 10 september 2004 @ 14:48:
Waneer je dus verchillende gebruikers hebt waarvan een aantal settings moeten worden bijgehouden (al dan niet met beveiligingen) dan zou je misschien kunnen opteren voor een database. Dan staat de data ook centraal en is gemakkelijk te backupen, ik denk dat je user - management er alleen maar gemakkelijk op wordt.

Als ik als gebruiker iets irritant vind, is dat ik voor applicatie X allemaal losse gebruikers moet aanmaken en me steeds apart bij applicatie X moet aanmelden, terwijl ik juist in Windows gebruikers heb aangemaakt, me bij Windows aanmeld als de juiste gebruiker, in Windows bestandspermissies kan regelen en Windows de mogelijkheid biedt om per gebruiker aparte instellingen op te slaan.

Kort gezegd: voor elke applicatie apart gebruikers beheren vind ik NIET makkelijker!

Wat mij betreft is die suggestie dus een absolute no-go. De enige fatsoenlijke redenen die ik er voor ken zijn portability (andere besturingssystemen hebben geen registry) en backward compatibility (Windows 9X was geloof ik niet zo sterk in het scheiden van data van gebruikers).

Het register zou ik nooit gebruiken want inderdaad wat doe je wanneer de hd wordt geformateerd ? Een database is gewoon veel gemakkelijker om mee te nemen naar een nieuwe pc bijvoorbeeld.

Tja, als je de harde schijf formatteert, moet je ook applicatie X opnieuw installeren. En jouw database moet ook geback-upt worden; waarom is het lastiger om een registry file te exporteren in plaats van een database dump?

Verder, hoe ga je te werk met roaming profiles? Jouw database bevat de gegevens van alle gebruikers, neem ik aan? Hoe wil je die gaan delen?

[.oisyn]

jos707 schreef op 10 september 2004 @ 14:48:
Het register zou ik nooit gebruiken want inderdaad wat doe je wanneer de hd wordt geformateerd ? Een database is gewoon veel gemakkelijker om mee te nemen naar een nieuwe pc bijvoorbeeld.

Het register staat uiteraard ook gewoon in bestanden, namelijk user.dat en system.dat voor win9x* .oisyn en de files in windows/system32/config voor win2k/xp. Het lijkt me dat er gewoon een mogelijkheid is deze te openen, hoewel ik de tools ervoor nooit gezien heb.

[ Voor 75% gewijzigd door .oisyn op 10-09-2004 15:02 ]

[jos707]

Soultaker schreef op 10 september 2004 @ 15:01:
....


Tja, als je de harde schijf formatteert, moet je ook applicatie X opnieuw installeren. En jouw database moet ook geback-upt worden; waarom is het lastiger om een registry file te exporteren in plaats van een database dump?

Verder, hoe ga je te werk met roaming profiles? Jouw database bevat de gegevens van alle gebruikers, neem ik aan? Hoe wil je die gaan delen?

Nu een registry file exporten (en opassen dat je niet andere/foute keys meeneemt) en later terug importeren is volgens mij toch minstens evenveel werk als gewoon een mdb bestandje copy/pasten. En heb je er ook al eens aan gedacht dat er windows pc's zijn die niet met profiles werken. Bv stel ik maak een applicatie voor in de bib van onze school waar elke leerling gewoon achter de pc kan zitten en gewoon kan inloggen/uitloggen.

[AtleX]

Ik maak in mijn applicaties bijna altijd de mogelijkheid om settings te backuppen. Verder sla ik instellingen altijd op in het register of in de applicatiefolder.

Indien meerdere gebruikers van het programma gebruik gaan maken met ieder hun eigen settings gebruik ik gewoon het register. Anders komt het in de applicatiefolder omdat veel mensen daar toch als eerste gaan zoeken. Ook vermeld ik in de handleiding altijd hoe settings gebackuped kunnen worden

[Verwijderd]

Soultaker schreef op 10 september 2004 @ 14:39:
Dat is inherent aan het hebben van meer entries in de registry database. Als je veel losse bestanden maakt, duurt het doorzoeken van al die bestanden ook langer dan het doorzoeken van weinig losse bestanden. Meer entries is meer entries, of je die nu in één conceptuele database stopt of in verschillende aparte.

Dat klopt niet, als ik de registry opsplits in meerdere databases van gerelateerde settings, dan zal ik nooit alle databases hoeven te doorzoeken (applicatie X heeft immers niks te zoeken in settings die alleen voor applicatie Y van belang zijn).

Dat is een kwestie van rechtenbeheer. Windows NT en verder bieden daar ondersteuning voor. Ik heb er zelf nooit mee gewerkt dus ik kan moelijk zeggen of die mogelijkheden adequaat zijn, maar het is hoe dan ook geen probleem met het hebben van een grote database. Een gewone applicatie kan ook onbeschermde bestanden van andere applicaties wijzigen of verwijderen, of de harde schijf volschrijven.

Het is wel een probleem veroorzaakt door het hebben van één enkele database. Als alleen gerelateerde settings in het zelfde bestand op disk kwamen te staan, dan kon je dat simpelweg afschermen met bestandsrechten en niet met een nieuwe laag van (foutveroorzakende) complexiteit in het rechtenbeheer.

In de praktijk vind ik dat installers/uninstallers onder Windows veel beter met instellingen kunnen werken dan menig ander systeem onder alternatieve besturingssystemen dat met platte configuratiebestanden werkt. Het kost de grootste moeite om op betrouwbare wijze regels toe te voegen aan dit soort ongestructureerde configuratiebestanden en bij het verwijderen van de software de instellingen weer te verwijderen.

Ongestructureerd? Ze zijn tekstueel gestructureerd en niet binair; dat biedt zowel voordelen als nadelen, maar daar wilde ik het eigenlijk niet over hebben want dat staat verder los van de beslissing om alles in een bestand te pleuren of een stricter concept toe te passen.

[Zoijar]

Ik weet niet of het al gezegd is, maar ik zou gaan voor een .xml file in je homedir. Dan is het ook meteen *nix compatible, eventueel voor een latere port.

[Soultaker]

Verwijderd schreef op 10 september 2004 @ 16:01:
Dat klopt niet, als ik de registry opsplits in meerdere databases van gerelateerde settings, dan zal ik nooit alle databases hoeven te doorzoeken (applicatie X heeft immers niks te zoeken in settings die alleen voor applicatie Y van belang zijn).

Je kunt dan ook best heel efficient zoeken in alle waarden onder "HKEY_LOCAL_USER\Software\Company\Product". Jij vergelijkt nu het doorzoeken van alle instellingen in de registry met het doorzoeken van de instellingen voor één applicatie in een configuratiebestand. Dat is appels met peren vergelijken. Zoals ik al zei: als je alleen een subkey doorzoekt is dat ook best snel en als je alle configuratiebestanden op een systeem moet doorzoeken duurt dat ook lang.

Verwijderd schreef op 10 september 2004 @ 16:01:
Ongestructureerd? Ze zijn tekstueel gestructureerd en niet binair; dat biedt zowel voordelen als nadelen, maar daar wilde ik het eigenlijk niet over hebben want dat staat verder los van de beslissing om alles in een bestand te pleuren of een stricter concept toe te passen.

Als je een beetje ervaring hebt met non-Windows software (of Windows-software die de registry niet gebruikt, for that matter, al is daar zelfs nog een INI-file API voor), dan weet je dat bijna elke applicatie er weer een ander formaat configuratiebestand op na houdt.

De afzonderlijke formaten zijn vaak wel gestructureerd, maar verschillende applicaties houden zelden dezelfde structuur aan. Dat maakt het dus lastig voor gebruikers én installers om makkelijk met die configuratiebestanden te werken. Er zit dus nauwelijks gemeenschappelijke structuur in. (Verder is het erg makkelijk om ongeldige syntax te gebruiken in zo'n configuratiebestand; met de Windows registry kan dat bijna niet.)

[Verwijderd]

Zoals eerder is gezegd vind ik het ook persoonlijk heel handig als je gewoon een applicatie kan backuppen door gewoon de root map te kopiëren. Dus in dat geval is het aan te raden om je settings gewoon in een afzonderlijk bestand in die map op te slaan. Dan wel in binaire vorm of in tekstvorm (bvb ini, xml, etc).

Natuurlijk heeft dan iedere gebruiker op de pc dezelfde settings.
[edit] Maar dan als je het reëel bekijkt: de meeste mensen gebruiken dezelfde settings in gedeelde programma's op een pc. En als dat niet zo is, dan kan je beter gebruikersprofielen programmeren in je programma zelf vind ik persoonlijk.

[ Voor 24% gewijzigd door Verwijderd op 10-09-2004 19:58 ]

[Verwijderd]

Verwijderd schreef op 10 september 2004 @ 16:01:
Dat klopt niet, als ik de registry opsplits in meerdere databases van gerelateerde settings, dan zal ik nooit alle databases hoeven te doorzoeken (applicatie X heeft immers niks te zoeken in settings die alleen voor applicatie Y van belang zijn).

dan kom je weer op de "oude" windows 3.11 INI-files uit, als die ook nog eens in een goede locatie gezet worden dan heb je IMHO een ideaal systeem.
( BV. de AppSettings en GLobal AppSettings mappen )

Soultaker schreef op 10 september 2004 @ 19:47:

Je kunt dan ook best heel efficient zoeken in alle waarden onder "HKEY_LOCAL_USER\Software\Company\Product". Jij vergelijkt nu het doorzoeken van alle instellingen in de registry met het doorzoeken van de instellingen voor één applicatie in een configuratiebestand.

als jij je settings opslaat in de registry, en een andere applicatie slaat ook de settings daar op, dan wordt het ophalen van jouw settings ook trager, normaal zal je dat nauwelijks merken, maar met bv een registry van enkelen honderden MB's merk je het wel degelijk, MS geeft dat zelf toe, en daarom zeggen ze ook geen grote hoeveelheden binary data in de registry op te slaan.

[Verwijderd]

Hmm alvast bedankt allemaal voor jullie antwoorden.
Aangezien ik vrij neutraal was voor ik jullie antwoorden begon te lezen, heb ik nu pas een mening gevormd.
(1) register lijkt mij nuttig, omdat ik maar weinig ga opslaan en omdat ik (persoonlijk) veel bestandjes op mijn harde schijf in (o.a.) die application data-map viezer vind dan register-mapjes.
(2) anderzijds hebben die app-data ook voordelen, want het register is zo'n beetje de vuilbak van windows.
(3) ik heb er over nagedacht, omdat het zo'n mooie oplossing is; maar de settings opslaan in de map van mijn programma zelf, is niet goed want ik wil gescheiden settings per gebruiker.

ten andere ook bedankt voor de opmerking om ook het versienummer bij te schrijven, zodat ik compatibiliteit kan inbouwen.

die settings back-uppen lijkt mij (voor mijn specifiek progje) niet nodig, maar dit geheel terzijde. 't is eerder op noob-niveau; back-ups zijn niet nodig denkek.

Iets anders; zo'n xml-bestand klinkt mij nogal ingewikkeld. Ik lees op de frontpage dat MICROSOFT (je weet wel, het bedrijf zonder dollarteken in z'n naam!) dat gaat gebruiken voor vanalles en nog wat, voor alle soorten office-bestanden enzovoort. Maar als ik het hier zo wat lees, is zo'n xml-bestand een gewoon tekstbestand? Daarmee bedoel ik; tekst, zoals .ini, .txt, .htm, .bat enzovoort; niet tekst zoals .doc of .pfd, die je kan opendoen met notepad waarna je zoveel zwarte blokjes en chinees te zien krijgt.
xml is dus eenvoudiger dan ik dacht?

[Soultaker]

XML is human editable/readable en je kunt het dus meestal wel editen met Notepad. Het voordeel is dat het een hiërarchische structuur oplegt; het is wat dat betreft te vergelijken met HTML al is het een stuk stricter. Het voordeel daarvan is dat je het automatisch kunt lezen en schrijven.

Hoewel het lezen en schrijven van (volledige) XML erg complex is (en complexer dan de meeste formaten die je zelf zou kunnen verzinnen) heb je het voordeel dat op praktisch elk denkbaar platform XML tools beschikbaar zijn die je kunt gebruiken. Effectief bespaar je daarmee tijd, als je deze tools eenmaal beheerst. Daarom is XML vaak een goed alternatief voor een eigen plain-text bestandsformaat.

Voor details onder Windows kun je je op de XML Developer Center wel inlezen in de materie. Daar staan ook voorbeelden van hoe de Microsoft XML libraries te gebruiken zijn.

(Overigens is Microsoft juist een van de bedrijven die geen XML gebruiken voor hun Office-bestanden. OpenOffice en KOffice doen dit bijvoorbeeld wel; bestanden daarvan zijn gewoon zipjes met XML-bestanden en plaatjes en dergelijke.)

[farlane]

.oisyn schreef op 10 september 2004 @ 13:44:
Ja fijn, elke user dezelfde settings

Dat ligt er maar helemaal aan hoe je je config inricht natuurlijk. Een file kan gegevens van meerdere users opslaan.

Er is niet voor niets een verschillende HKEY_CURRENT_USER en Appdata dir voor elke user op het systeem.

Ongetwijfeld; als ik user X verwijder is dan de Appdate dir van X ook weg ?

Dit vind ik een beetje onzin. Het registry is niet bloated, er staat gewoon veel in. Er is dan ook veel info om op te slaan.

Het is niet erg als er veel in staat; maar als er veel in staat wat er niet meer in hoeft te staan noem ik dat bloat. Ik run crapcleaner geregeld, en op een of andere manier vind ie telkens weer keys die niet gebruikt worden of invalid zijn, naar niet bestaande programmas wijzen en weet ik niet wat.

Heb je de linux config files weleens gezien? Die staan helemaal overal en nergens, in windows staan ze tenminste allemaal op dezelfde plek

Normaal staan de user afhankelijke configs vaak in de user dir op een linux systeem, en de global configs in etc of daaronder. ( Ik beweer overigens ook niet dat de linux manier beter is; van de 10000 verschillende formaten van configs wordt je ook helemaal dol van )

Ik weet alleen wel dat het register onder windows een ongelooflijke bak rotzooi is, en ik me dood erger aan al die 'speciale directories' die mn MS programma's aanmaken. ( MS games maken een 'My Games' dir aan voor savegames, VS.NET maakt een 'MS help' directory aan in 'All users' en plempte daar bij mij zon 800 MB aan 'compiled help files' in. Aaargh ! )

Mij lijkt een systeem waarbij je per applicatie een registry file hebt in de app dir gewoon veel praktischer. Het systeem zoals het nu is werkt gewoon niet.

Maar verder vallen mijn frustraties best mee

[farlane]

Verwijderd schreef op 10 september 2004 @ 20:10:
(3) ik heb er over nagedacht, omdat het zo'n mooie oplossing is; maar de settings opslaan in de map van mijn programma zelf, is niet goed want ik wil gescheiden settings per gebruiker.

Dat kan dan toch nog steeds of ben ik nu gek ?

[Soultaker]

farlane schreef op 10 september 2004 @ 21:45:
Normaal staan de user afhankelijke configs vaak in de user dir op een linux systeem, en de global configs in etc of daaronder.
[..]
Het is niet erg als er veel in staat; maar als er veel in staat wat er niet meer in hoeft te staan noem ik dat bloat. Ik run crapcleaner geregeld, en op een of andere manier vind ie telkens weer keys die niet gebruikt worden of invalid zijn, naar niet bestaande programmas wijzen en weet ik niet wat.

Ik moet mijn UNIX-homedirs ook vaak opschonen, omdat ze volstaan met dot-files (feitelijk directories meestal) van applicaties die ik allang niet meer geïnstalleerd heb. Dat probleem hou je dus toch en is vooral afhankelijk van de hoeveelheid wazige applicaties waarmee je experimenteert, ongeacht het besturingssysteem. (En ik experimenteer nu eenmaal meer onder UNIX dan onder Windows.)

farlane schreef op 10 september 2004 @ 21:45:
Ik weet alleen wel dat het register onder windows een ongelooflijke bak rotzooi is, en ik me dood erger aan al die 'speciale directories' die mn MS programma's aanmaken. ( MS games maken een 'My Games' dir aan voor savegames, VS.NET maakt een 'MS help' directory aan in 'All users' en plempte daar bij mij zon 800 MB aan 'compiled help files' in. Aaargh ! )

Dat herken ik ook (en dan die ellende van 'My Visual Studio Projects' en 'My Paint Shop Pro Files' die ik niet wil hebben en op een Nederlands systeem dubbel lelijk zijn), maar dat ligt dus vooral aan die applicaties en niet aan Windows en de registry API. (Gek genoeg krijgt Microsoft het maar niet voor elkaar om ervoor te zorgen dat tenminste hun eigen applicaties zich aan hun eigen standaarden houden).

[Verwijderd]

Soultaker schreef op 10 september 2004 @ 21:53:
Ik moet mijn UNIX-homedirs ook vaak opschonen, omdat ze volstaan met dot-files (feitelijk directories meestal) van applicaties die ik allang niet meer geïnstalleerd heb. Dat probleem hou je dus toch en is vooral afhankelijk van de hoeveelheid wazige applicaties waarmee je experimenteert, ongeacht het besturingssysteem. (En ik experimenteer nu eenmaal meer onder UNIX dan onder Windows.)

Idem dito, maar wat is eenvoudiger, directories/files weggooien of een 3d-party vendor tool op de registry loslaten en hopen dat je systeem nog leeft na de operatie. (Voor alle users een .blahrc file/dir verwijderen is niet moeilijker dan een find /home -maxdepth 2 -name .blahrc -exec rm -rf '{}' \; maw. je kunt de unix toolset loslaten op je rcfiles, daarom hebben ze ook een tekstuele structuur.)

[Olaf van der Spek]

Verwijderd schreef op 10 september 2004 @ 16:01:
Het is wel een probleem veroorzaakt door het hebben van één enkele database. Als alleen gerelateerde settings in het zelfde bestand op disk kwamen te staan, dan kon je dat simpelweg afschermen met bestandsrechten en niet met een nieuwe laag van (foutveroorzakende) complexiteit in het rechtenbeheer.

Een database, een filesystem, wat is het verschil?
Misschien dat de (huidige) implementatie van de registry niet optimaal is, maar er is geen reden waarom het concept langzamer zou moeten zijn dan een filesystem/file.
Sterker nog, de FS oplossing is IMO slechter, omdat je of tig losse files krijgt of elke keer je hele config file moet overschrijven als je een enkele entry edit.
Het register heeft trouwens ook gewoon rechtenbeheer.

Mij lijkt een systeem waarbij je per applicatie een registry file hebt in de app dir gewoon veel praktischer. Het systeem zoals het nu is werkt gewoon niet.

Normal users hebben geen write access in de app dir, dus hoe wou je dat oplossen?
En hoe werkt jouw oplossing als de Documents and Settings tree op een netwerk drive staat?
Heb je dan op elke computer weer andere instellingen?

[ Voor 24% gewijzigd door Olaf van der Spek op 12-09-2004 00:17 ]

[kenneth]

Verwijderd schreef op 10 september 2004 @ 19:58:
Maar dan als je het reëel bekijkt: de meeste mensen gebruiken dezelfde settings in gedeelde programma's op een pc. En als dat niet zo is, dan kan je beter gebruikersprofielen programmeren in je programma zelf vind ik persoonlijk.

Waarom zou je het wiel opnieuw uitvinden Gebruikersprofielen zitten al standaard in Windows. Gebruik ze, zou ik zeggen ...

[Verwijderd]

OlafvdSpek schreef op 12 september 2004 @ 00:14:
Een database, een filesystem, wat is het verschil?

Zoals ik al aangaf spreken we normaal pas van een database als er een of meer relaties tussen opgeslagen gegevens bestaan.

Misschien dat de (huidige) implementatie van de registry niet optimaal is, maar er is geen reden waarom het concept langzamer zou moeten zijn dan een filesystem/file.

In de praktijk echter, werkt een bestand met volledig gespecificeerd pad op een 120 GB schijf zoeken vele malen sneller dan een volledig gespecificeerde key in een 300MB registry zoeken...

Sterker nog, de FS oplossing is IMO slechter, omdat je of tig losse files krijgt of elke keer je hele config file moet overschrijven als je een enkele entry edit.
Het register heeft trouwens ook gewoon rechtenbeheer.

Dit is een probleem van text vs. binary formaten en heeft niets te maken met de keuze om alle settings van alle applicaties maar in een bestand te pleuren (dit heb ik al eens gezegd in dit topic; ik heb ook iets gezegd over het nadeel van een speciaal rechtensysteem bouwen terwijl het ook simpelweg met reeds geïmplementeerde bestandsrechten op te lossen is.)

Normal users hebben geen write access in de app dir, dus hoe wou je dat oplossen?

Normal users kunnen ook geen applicaties (systeemwijd) installeren of deïnstalleren, ik neem aan dat als je genoeg rechten hebt om een voor alle users beschikbare applicatie van het systeem te verwijderen, je ook genoeg rechten hebt om de .rcfiles uit de userdirectories te verwijderen.

En hoe werkt jouw oplossing als de Documents and Settings tree op een netwerk drive staat?
Heb je dan op elke computer weer andere instellingen?

Net als bij windows zal een deel van de settings beschikbaar moeten zijn nog voordat de machine in het netwerk zit (daarom is de registry ook opgesplitst in meerdere bestanden), dat deel zal dus lokaal op de machine moeten worden opgeslagen, de rest kan net zo makkelijk op een network mount/share staan.

[Olaf van der Spek]

Verwijderd schreef op 12 september 2004 @ 03:53:
Zoals ik al aangaf spreken we normaal pas van een database als er een of meer relaties tussen opgeslagen gegevens bestaan.

Dan spreken we over een relationale database, maar er zijn toch nog wel andere databases?

In de praktijk echter, werkt een bestand met volledig gespecificeerd pad op een 120 GB schijf zoeken vele malen sneller dan een volledig gespecificeerde key in een 300MB registry zoeken...

Ok, maar dat zegt weinig over het concept.

Dit is een probleem van text vs. binary formaten en heeft niets te maken met de keuze om alle settings van alle applicaties maar in een bestand te pleuren (dit heb ik al eens gezegd in dit topic; ik heb ook iets gezegd over het nadeel van een speciaal rechtensysteem bouwen terwijl het ook simpelweg met reeds geïmplementeerde bestandsrechten op te lossen is.)

Register rechten zijn toch ook reeds geimplementeerd?

Normal users kunnen ook geen applicaties (systeemwijd) installeren of deïnstalleren, ik neem aan dat als je genoeg rechten hebt om een voor alle users beschikbare applicatie van het systeem te verwijderen, je ook genoeg rechten hebt om de .rcfiles uit de userdirectories te verwijderen.

Dit ging niet om uninstallen, maar om alle settings in de appdir. En ik nam aan dat farlane met appdir \Program Files\ bedoelde en niet \Documents and Settings\*\Application Data\.

[Verwijderd]

OlafvdSpek schreef op 12 september 2004 @ 12:01:
Dan spreken we over een relationale database, maar er zijn toch nog wel andere databases?

Klopt, je hebt bv. hierarchische databases waar uitgegaan wordt van een hierarchische ordening (= relatie) van de opgeslagen data, of object-georiënteerde databases waar men uitgaat van is-een of heeft-een relaties van de opgeslagen data.

Ok, maar dat zegt weinig over het concept.

Het zegt wel wat over het idee om houten wielen te bedenken terwijl er formule-1 banden naast je in het rek staan.

Register rechten zijn toch ook reeds geimplementeerd?

En worden door zo goed als niemand gebruikt omdat ze zo complex zijn. Daarnaast beschermen register rechten je niet tegen een applicatie die (volledig legaal) haar namespace volschrijft met megabytes aan binary data. In een filesystem bieden quota een uitweg.

Dit ging niet om uninstallen, maar om alle settings in de appdir. En ik nam aan dat farlane met appdir \Program Files\ bedoelde en niet \Documents and Settings\*\Application Data\.

Ik citeer Soultaker ff:

Ik moet mijn UNIX-homedirs ook vaak opschonen, omdat ze volstaan met dot-files (feitelijk directories meestal) van applicaties die ik allang niet meer geïnstalleerd heb.

[Verwijderd]

kenneth schreef op 12 september 2004 @ 00:24:
[...]
Waarom zou je het wiel opnieuw uitvinden Gebruikersprofielen zitten al standaard in Windows. Gebruik ze, zou ik zeggen ...

Omdat ik graag de optie voor het gebruik in andere operating systems open houd.

[Olaf van der Spek]

Verwijderd schreef op 12 september 2004 @ 16:32:
Omdat ik graag de optie voor het gebruik in andere operating systems open houd.

En andere operating systems kennen geen gebruikersprofielen?

Verwijderd schreef op 12 september 2004 @ 16:16:
Ik citeer Soultaker ff:

Soultaker? Ik reageerde op farlane:

farlane schreef op 10 september 2004 @ 21:45:
Mij lijkt een systeem waarbij je per applicatie een registry file hebt in de app dir gewoon veel praktischer. Het systeem zoals het nu is werkt gewoon niet.

En worden door zo goed als niemand gebruikt omdat ze zo complex zijn. Daarnaast beschermen register rechten je niet tegen een applicatie die (volledig legaal) haar namespace volschrijft met megabytes aan binary data. In een filesystem bieden quota een uitweg.

Per-user quota en per-user rights beschermen toch zowel \Documents and Settings\*\ als HKEY_CURRENT_USER (omdat de per-user reg in D&S staat)?

[ Voor 73% gewijzigd door Olaf van der Spek op 12-09-2004 16:39 ]

[Verwijderd]

OlafvdSpek schreef op 12 september 2004 @ 16:33:
[...]

En andere operating systems kennen geen gebruikersprofielen?

Mss een late reply, maar:
Andere besturingssystemen hebben mogelijk (maar niet altijd) gebruikersprofielen. Het punt is dat de implementatie van deze dan ook niet steeds het zelfde wordt toegepast. Natuurlijk kan je dan zeggen: ok, doe het dan met een abstracte basisklasse en pas deze dan toe per OS. Dan vind ik het eigenlijk gewoon makkelijker en duidelijker (en minder werk) om gewoon alles even naar een bestand weg te schrijven in binaire data. Je hoeft dan weinig of niks meer aan te passen als je naar een ander OS porteert.
Maar natuurlijk hangt het er van af waarvoor je toepassing bedoelt is.

[Olaf van der Spek]

Verwijderd schreef op 05 oktober 2004 @ 01:59:
Dan vind ik het eigenlijk gewoon makkelijker en duidelijker (en minder werk) om gewoon alles even naar een bestand weg te schrijven in binaire data.

Hopelijk wel in \documents & settings\*\ en niet in \program files\ dan?
En qua code is het zeker eenvoudiger, maar is het formaat ook nog back- en forwards compatible?
En hoe eenvoudig kunnen andere apps de settings wijzigen?

[Verwijderd]

OlafvdSpek schreef op 05 oktober 2004 @ 08:50:
[...]

Hopelijk wel in \documents & settings\*\ en niet in \program files\ dan?
En qua code is het zeker eenvoudiger, maar is het formaat ook nog back- en forwards compatible?
En hoe eenvoudig kunnen andere apps de settings wijzigen?

Nee, juist in de map waar het programma ook staat. Want op een ander OS ga je de docs&settings of program files mappen niet terugvinden.

Het formaat kan je zelf ontwikkelen. Als je XML gebruikt, dan is het zelfs makkelijk om backwards compatible te maken. Er zijn zat libraries om XML uit te lezen, dus andere apps zouden dan makkelijk jouw settings kunnen inlezen.
Als je echt binair wil wegschrijven, dan ga je (in C++) gewoon een struct oid maken met alle data in die struct. 't Is dan iets moeilijker om backwards compatible te maken, maar zeker niet onmogelijk.

[RobIII]

Ik heb een paar keer de opmerking Database voorbij zien komen, maar dan als zijnde de "registry database" e.d.
Ik heb een app die op verschillende systemen (binnen en buiten een NT-domein) gebruikt wordt. Users willen toch overal hun settings hebben, en die settings meenemen op flop/memorystick/whatever is natuurlijk geen optie. Je kunt werken met roaming profiles in een domein, maar dan gaat het weer mis als je niet in het domein zit en toch die app gebruikt. Ik heb dat (makkelijkste weg) opgelost door gewoon een config in .xml te maken, en die sla ik op in een "memo/blob/text" veld van MSSQL in de users tabel. Dit werkt natuurlijk prachtig.

En als je dan toch een .SaveToDB method maakt die de XML saved naar de DB en een .LoadFromDB die de config uit de DB ophaalt, dan heb je natuurlijk ook zo een .SaveToFile en .LoadFromFile method die hetzelfde bestand ergens anders vandaan haalt (guess what: Het filesystem ). En als je dan toch bezig bent, wat dacht je van .LoadFromHTTP en .SaveToHTTP... Of .LoadFromNoemmaarietsop en .SaveToNoemmaarietsop

Op deze manier zijn je settings:
a) toch roaming (natuurlijk vermits je van buitenaf bij je DB kunt, in mijn geval MSSQL via een webservice),
b) multi-user geschikt,
c) makkelijk te ex/importeren,
d) human readable/editable,
e) hiërarchisch,
f) makkelijk uitbreidbaar en backwards compatible te houden,
g) op bepaalde node-niveaus makkelijk te kopieëren naar andere gebruikers ("hey, jij hebt dat handig/mooi ingesteld, dat wil ik ook!") of natuurlijk compleet te kopieëren.
h) geen geklooi met wel/geen rechten om te schrijven in <somedir> als je de DB methode gebruikt
i) de gemiddelde "pruts0r" kan niet rechtstreeks je settings editten tenzij 'ie in de DB_{evt. met wachtwoord beveiligd} kan en dus een beetje SQL/XML kennis heeft. Regedit en notepad zijn snel / makkelijk gestart

Ik heb sowieso een "default user", een beetje vergelijkbaar met het "all users" profiel onder Windows. Deze default user bevat de instellingen zoals deze horen te staan voor nieuwe users en dus heb je bij een nieuwe user zo een kopietje gemaakt en staan zijn settings meteen "company default"

Echte nadelen heb ik nog niet ondervonden...

Een voorbeeldje van hoe de settings er voor 1 user uit zouden kunnen zien:

code:

<Settings version="1.1.0" author="MyName" lastchangedate="2004-01-26T15:29:01">
    <Algemeen>
        <Opties>
            <StartupSplash type="boolean">-1</StartupSplash>
            <DefaultUser type="string">Rob</DefaultUser>
            <ReportPath type="string">C:\Program Files\Mijnapp\reports</ReportPath>
            <LastLogin type="date">2004-01-26T15:29:01</LastLogin>
        </Opties>
    </Algemeen>
    <Reports>
        <Report naam="Factuur.rpt">
            <Printer type="string">\\server\hplj5</Printer>
            <PaperSize type="string">a4</PaperSize>
            <PaperBin type="integer">4</PaperBin>
        </Report>
        <Report naam="Klantlijst.rpt">
            <Printer type="string">\\server\hplj4200</Printer>
            <PaperSize type="string">a3</PaperSize>
            <PaperBin type="integer">1</PaperBin>
        </Report>
    </Reports>
</Settings>

Zoals je ziet is het een beetje een "hybride" bestand, in de zin van dat er een soort DTD/XSD in de XML zelf is opgenomen waardoor settings niet gauw verkeerd kunnen worden geïnterpreteerd. Tevens heeft de methode .GetSetting een optionele parameter waarin een eventuele default waarde kan worden opgegeven mocht er een setting niet gevonden worden of niet voldoen aan het juiste "type" (integer/string etc).

Natuurlijk zou je ook de settings van alle users in 1 XML kunnen opslaan door voor iedere user een node te maken met daarin de settings. Ik heb daar bewust niet voor gekozen, juist vanwege het multi-user karakter van mijn applicatie (zodat niet opeens 2 man zitten frotten in 1 record/bestand).

_{Disclaimer: Ik heb helemaal niks tegen het registry, de application data directories enzovoorts, en wat ik hier uitleg zou je relatief net zo makkelijk met een .ini of anderssoortig bestand kunnen oplossen, maar ik vond dit persoonlijk de mooiste/handigste oplossing voor mijn app.
Gebruik gewoon in het juiste geval de juiste oplossing. Als je maar 1 getalletje dient te onthouden voor een user, kun je dit natuurlijk net zo makkelijk in het register of ergens anders bij houden, en is een DB of een XML bestand natuurlijk overkill...Maar dat begreep je zelf ook al Use the right tool for the right job}

[ Voor 113% gewijzigd door RobIII op 05-10-2004 17:36 ]

[Olaf van der Spek]

Verwijderd schreef op 05 oktober 2004 @ 12:26:
Nee, juist in de map waar het programma ook staat. Want op een ander OS ga je de docs&settings of program files mappen niet terugvinden.

Je weet dat gewone users niet naar \Program Files\ kunnen schrijven?

[RobIII]

OlafvdSpek schreef op 05 oktober 2004 @ 14:47:
[...]



Je weet dat gewone users niet naar \Program Files\ kunnen schrijven?

En dat soort ongein voorkom je dus ook nog eens met mijn "oplossing" die hierboven beschreven staat...

[Verwijderd]

OlafvdSpek schreef op 05 oktober 2004 @ 14:47:
[...]



Je weet dat gewone users niet naar \Program Files\ kunnen schrijven?

Mja, ok, das stom van mij :x
Dan ga ik voor de optie dat de user(of admin) zelf kan configureren waar het bestand voor de configuratie heen moet. Dan kan hij in windows een windows path geven en in weet-ik-veel-wat-os een ander path.

En dan is het wel handig om even een stukje code te maken dat automatisch - in Windows dan - de docs&settings map gebruikt van de desbetreffende user. Maar dat zou ik dan niet in de "core" code zetten, maar eerder afzonderlijk, bvb in een configuratietool bij de installatie ofzo.

[Olaf van der Spek]

bvb in een configuratietool bij de installatie ofzo.

De administrator installeert de boel en de users gebruiken de boel.
Elke user heeft zijn eigen D&S.
De D&S dir moet je dus echt op run-time opvragen.

[Verwijderd]

OlafvdSpek schreef op 05 oktober 2004 @ 19:42:
[...]

De administrator installeert de boel en de users gebruiken de boel.
Elke user heeft zijn eigen D&S.
De D&S dir moet je dus echt op run-time opvragen.

In Windows ja Ter veronderstelling dat je de D&S map gebruikt. Voor hetzelfde geld heeft iedere gebruiker een netwerk-map. Maar als je enkel in Windows wil werken, dan ga ik volledig akkoord met je werkwijze.

[Olaf van der Spek]

Verwijderd schreef op 05 oktober 2004 @ 22:42:
In Windows ja

In Linux en vrijwel elk ander OS kennen ze het concept (per-user) home dir ook hoor.
En in Windows kan D&S ook vanaf een netwerk drive worden geladen tijdens het inloggen.

[ Voor 18% gewijzigd door Olaf van der Spek op 06-10-2004 15:55 ]