Zitat von
Assarbad:
Bei Internet/Datenbank wäre ich persönlich vorsichtig. An sich keine schlechte Idee, aber Datenbanken sind immer relativ groß ... und meist auch zugehörige
API-Sammlungen (bspw.
BDE).
Sowas würde ich nur als Plugin dazuliefern (ich persönlich bin zB skeptisch wenn ein Programm "Internetfunktionen" enthält
).
Ich dachte eher an ein .XML - File das zu den Keys die Erklärungen erhält. Wenn eine neue vom Benutzer selber eingetragen wird, wird diese (nur die einzlene Änderung) zusätzlich in weiteres .XML gapackt, das der User dann beim nächsten Update seiner Beschreibungsdatenbank auch mit hochlädt. Somit füllt sich die Beschreibungsliste Stück für Stück durch die Mithilfe der Benutzer. Zumindest war das mein Ansatz
Zitat von
Assarbad:
Was meinst du mit
- Snapshot-Vergleiche von verschiedenen Situationen.?
- Verwaltung von Profilen oder Konfigurationen, die bestimmte Kombinationen von Registry-Settings erlauben?
Das erste hatte ich mir gedacht für eine Versionierung. Ich mache jetzt einen Snapchot (oder Dump) der Registry, und installiere z.B. eine Software. Alle Änderungen die dadurch gemacht werden werden dann zusammengefasst (ála Diff) und diese können dann gemeinsam z.B. exportiert werden, der Ursprungszustand wiederhergestellt werden etc.
In Verbinundg mit Profilen erlaubt dies z.B. das Betreiben oder Testen mehrerer Installationen der gleichen Software an unterschiedlichen Orten etc. Das ist vor allem für Entwickler interessant, die in ihrer Software sehr viel mit der Registry arbeiten.
Zitat von
Assarbad:
Das letzte hier, zielt nur auf eine Erweiterung der Fähigkeiten von REGEDIT ab, oder?
- Export einzelner Werte in .REG's (bisher ja leider nur immer ganze Teilbäume möglich)
Japp. Ich kann in Regedit nur Schlüssel aus dem Baum exportieren, nicht einzelne Werte. Ich hatte mir das so Vorgestellt, daß der User neben der bekannten Ansicht noch einmal das ganze in einem eigenen Fenster hat, in das er einzelne Keys oder ganze Teilbäume ziehen kann, und diese Kombination aus Keys und Werten dann als ein einziges .REG abspeichern kann.
Mit dieser Speicherart würde ich auch die Verwaltung von Profilen ablegen.
Zitat von
Assarbad:
BTW: Einzelne Funktionalitäten könnten schon (aber streng objektorientert) angefangen werden. ZB der Export in .REG-Files. Da ich ja eine Klasse TNativeRegistry schreiben will, sollte eine Migration danach sehr leicht sein.
Das ist klar. Nur die Exportfunktion würde ich nicht vorher machen
Was man z.B. machen könnte wäre eine Trennung der Zugriff- und Speicherfunktionen. Ich würde die Datenstrukturen intern als
XML verwalten (um so einen schnellen Export zu gewährleisten) und um eben was z.B. die Erklärung der Keys angeht sehr flexibel zu sein.
Somit gäbe es die Klasse, die die Daten aus der Registry liest und hineinschreibt und die Klasse, die die Datenstrukturen verwaltet, diese Visualisiert und die Im- und Exportfunktionen zur Verfügung stellt.
Da bin ich aber für andere Ideen immer offen
Ps: Ich habe ja schon einiges, was aber auf einer erweiterten TRegistry aufsetzt. Da das mit der Zeit gewachsen ist wollte ich das eh wegwerfen und ggf. nur noch Codeschnipsel wiederverwenden, wenn es Sinn macht.