Office: UserForm Daten speichern. Registry oder externe Datei?

Hallo liebe Leute,

ich hätte gerne Rat von euch zu meinem Problem.
Gerne würde ich in einer UserForm Einträge speichern, die zu späterem Zeitpunkt wieder gebraucht werden.
Kurze Beschreibung:
Hier geht es um einzelne Projekte. Ich arbeite mit einer Multi-Page auf der UserForm.
Man startet die Datei und definiert bei Projekt-Start einzelne Werte auf MultiPage-Seite 1. Unter anderem das Enddatum des Projekts.
Bei Projekt-Ende wird die Datei wieder aufgerufen. Hier erfolgt ein Abgleich ob das eingetragene Enddatum auch schon erreicht ist. Dann wird die MultiPage-Seite2 freigeschaltet um die Ergebnisse einzutragen. Einzelne Werte werden hier von Seite 1 übernommen und später alles verglichen und in eine Excel-Datei geschrieben.

Bisher habe ich zwei Varianten gefunden.
Variante 1 ist das Speichern in der Registry.
Folgenden Code habe ich aus diesem Beitrag: http://www.ms-office-forum.net/forum/showthread.php?t=332664

Klassenmodul:
Code:

Aufruf in der UserForm: Code:

Variante 2 wäre mit einer ini-Datei.

Da ich es bevorzugen würde, dass ich keine Zusätzliche ini-Datei habe, fände ich die Variante 1 besser.
Hier habe ich nur das Problem, dass das nur mit einer Excel-Datei geht. Sobald der Nutzer zwei oder mehr Projekt-Dateien hat, geht das nicht mehr, da nur dieser eine Inhalt aufgerufen wird.
Außerdem bin ich mir unsicher, ob man mit der Registry arbeiten sollte.

Meine Fragen:
- Macht es Sinn das über die Registry zu machen? Wird die dadurch unnötig zugemüllt? (über 30 Steuerelemente auf Seite 1)
- Ginge es zu realisieren, dass bei der Variante über die Registry auch mehrere Dateien (Projekte) laufen die alle in der Registry unterschiedliche Daten speichern?
- Gäbe es bessere Alternativen?


Die Variante, die Daten ins Tabellenblatt schreiben und bei Neustart wieder auszulesen, finde ich auf Grund des Umfangs etwas viel. Außerdem habe ich auch Listboxen mit Mehrfachauswahl dabei, was den Zellbezug beim Auslesen erschwert.

Ich freue mich über Meinungen. Danke *Smilie

:)

 

Hallo,

nein (auch aus anderen Gründen) und ja. Die Registry halte ich nicht dafür geeignet, um Daten aufzuheben.

ja, z. B. über einen anderen Projektnamen

ja!
Diese hier:

wäre aber mein Favorit, gerade wenn es so viele Daten sind. Das Blatt zum Speichern der Daten kann ja ein verstecktes Blatt sein.

Wenn die Auswahlmöglichkeiten immer gleich bleiben, genügt es, den Index des gewählten Eintrags zu sichern, ansonsten die ausgewählten Werte (bei mehreren: mit z. B. Komma getrennt). Die Umsetzung dieser Aufgabe über die Registry wäre sicher nicht einfacher. Listboxen / Comboboxen mit Zellbezug halte ich ohnehin für nicht geeignet, da nicht flexibel genug. Ich baue die Listen grundsätzlich per VBA auf, ohne Zellbezug.

Grüße
EarlFred

 

Hallo,

Der Code sieht das doch bereits vor. Du brauchst nur beim Aufruf von getFormSettings, saveFormSettings und killSetting die optionale Variable sAppName gefüllt mit zu übergeben. Wenn Du eindeutige Projektnamen hast, ist das schnell gemacht.

Aber ja doch! Da wird nichts zugemüllt und der entsprechende Abschnitt in der Registry ist von Microsoft zusammen mit den Standardbefehlen genau dafür eingebaut worden.
@EarlFred - 'tschuldigung EarlFred: in dieser Beziehung stimme ich Dir überhaupt nicht zu. Das Sichern diverser UserForm-Eingaben mache ich so seit 20 Jahren und bei sehr vielen Rechnern und Anwendern, ohne dass je eine Registry geplatzt wäre.

 

Frage: Was passiert, wenn ich die Datei auf einem anderem Rechner kopiere?
Muss ich die Einträge aus der Reigstry auch kopieren? Wenn ja, dann gehören die Daten da nicht hin.

 

Hallo!

Die Registrierungsdatenbank ist m.E. nur dann wirklich sinnvoll wenn Daten an einen PC gebunden sein sollen. Das wären z.B. ein Lizenzschlüssel oder Einstellungen die nicht unbedingt in einer kopierbaren Datei stehen sollen.

Gruß, René

 

\@haklesoft

Du brauchst Dich doch nicht entschuldigen - Du hast doch nur Deine Meinung mitgeteilt, die eben von meiner abweicht.

Ich nutze die Registry nicht als Datenablage, weil
- die Daten an den jeweiligen Rechner gebunden sind. Das mag in Einzelfällen sinnvoll sein, die für meine Anwendungen in der Regel aber nicht zutreffen (ich habe alleine mehrere permanente Arbeitsplätze...)
- Deine Anwendungen ausgenommen: Wer kümmert sich darum, dass die Registry auch wieder bereinigt wird?
- hier ist von "viel Umfang" die Rede (ohne nähere Definition). Spätestens damit habe ich Sorge um die Registry.

Bis auf wenige Ausnahmen sehe ich die Registry daher nicht als den geeigneten Ablageort für DATEN.

Grüße
EarlFred

 

Super, vielen Dank euch für eure Meinung!
Dass das nur Sinn macht, wenn es immer auf dem selben Rechner verwendet wird, stimmt natürlich. Ich bin mir gerade auch unsicher wie das ist, wenn das mal auf einer Win-Server-Oberfläche läuft. Wenn der Nutzer sich nur mit einem Client anmeldet, weiß ich nicht ob die Registry diese Einträge so lange speichert wie ich das gerne hätte.

Ich werde mal eine Beispieldatei in gekürzter Form bauen, wie das bei mir aussieht. Vielleicht hat dann doch jemand einen Tipp, wie ich das gut hinbekomme mit dem Vorschlag von EarlFred.

Dennoch würde mich interessieren wie du das genau gedacht hast haklesoft.

Was mir gerade noch unklar ist:
- Mit was wird denn die sAppName gefüllt? Ich verstehe das nicht. Wie wird die Variable individuell für meine Datei?
Das müsste doch diese Zeile sein, oder?
If Len(sAppName) < 1 Then sAppName = csAPP

-

Meinst du so? Code:

- Habe ich das eigentlich richtig verstanden, wenn ich die Einträge in der Registry wieder löschen will, dann baue ich das so ein:
Code:

 

Das bedeutet, Du kannst viel schneller und einfacher in die Registry oder in eine externe Datei schreiben und dort lesen als in einem Excelsheet? Das sollte einen verwundern und dazu ermutigen, eigentliche Grundlagen aufzufrischen.

Zum anderen implizieren Deine Äußerungen, das Userform schwebt frei zwischen den Welten. Ist es nicht eher so, dass das Userform ein Objekt einer Mappe ist und somit aus dieser heraus definiert und bedient werden sollte? Was würde bspw. passieren, wenn mehrere verschiedene Userforms mit zufällig gleichen Bezeichnungen gleichzeitig in Betrieb sind?

 

\@EarlFred:

Die in meinen Word-Projekten in der Registry gespeicherten Eingaben und Einstellungen sind auf den jeweiligen Anwender am Arbeitsplatz bezogen. Zieht der Anwender um oder bekommt einen neuen Rechner werden auch die Registrydaten transferiert. Die fertigen Word-Dokumente mit den umgesetzten Eintragungen können beliebig verteilt werden und haben keinen Bezug zur Registry.

Beim Aktualisierungs-Setup meiner Anwendungen werden nicht mehr benötigte Registryabschnitte mit entfernt.

"Viel Umfang" wäre für die größenbeschränkten Ini-Dateien auch ungünstig.

 

Hallo Boerny610,

das hast Du nicht ganz richtig verstanden. Du solltest einen Projektnamen beim Aufruf übergeben, wobei "meinProjektname" ein Text oder eine Variable mit Deinem Projektnamen ist: Code:

 

Sorry, hat ein bisschen gedauert die Beispieldatei aufzubauen, deshalb melde ich mich erst jetzt.


@haklesoft
Danke. Ich schau mal ob ich das richtig verstanden habe und gib Bescheid, falls ich nicht klar komme.

@ebs17

Das bedeutet, Du kannst viel schneller und einfacher in die Registry oder in eine externe Datei schreiben und dort lesen als in einem Excelsheet? Das sollte einen verwundern und dazu ermutigen, eigentliche Grundlagen aufzufrischen.

Der Umfang war auf die Länge des Codes bezogen. Ich bin der Meinung das wird ziemlich viel Code, wenn ich die Inhalte aus dem Tabellenblatt wieder zurück in die UF schreiben möchte.

Hierzu habe ich nun mal eine stark gekürzte Version meiner Datei angehängt, vielleicht macht es das etwas deutlicher.
Auf der Seite "Anmeldung" ist noch ungefähr 1/3 der Eingabefelder vorhanden.
Da die Felder von der Reihenfolge so sein sollen, ist das im Code ein bisschen ein Durcheinander, da ja Combo/List/TextBoxen alle unterschiedlich ausgelesen werden.
Ich schreibe die Anmeldung auch bewusst zweispaltig in das Tabellenblatt, da das später übersichtlich lesbar sein soll. (Habe nur noch nicht eingebaut, dass die Spaltenbreite dem Text angepasst wird).

Wenn hier nun jemand eine Idee hat, wie ich den Inhalt aus dem Tabellenblatt wieder in die UserForm zurückbekomme, wäre toll. Wie ich grundsätzlich Zellen auslese um sie in die UserForm zu bekommen, ist ja klar. Ich steige da aber nicht ganz durch, da ich keinen festen Zellbezug habe, wenn der Text in das Blatt geschrieben wird.
Eine "mache-alles-rückwärts-Funktion" wäre der Hit *biggrin.gif* .

Zur Info:
Wenn ich die Datei (erneut zur Abmeldung) starte, würde ich abfragen, ob bereits Eintragungen vorhanden sind und Heute das bereits eingetragene Abmeldedatum erreicht ist. Wenn ja, dann werden Daten auf die Seite "Abmeldung" übernommen und alle Felder darauf freigeschaltet. (auch ca. 30 Felder)

 

Wenn es nur das wäre: Das geht mit einer einzigen Codezeile!
Aber warum sollte eine andere Variante weniger Code benötigen?
Das ist und darf nicht Kriterium gegen eine sinnvolle Lösung sein!

 

hier noch ein Mustercode:
Code:

codezeilen- und laufzeitreduziert:
Code:

 

Wer bestimmt denn, WIE der Text in das Tabellenblatt geschrieben wird?

Ein Mensch einerseits und Code andererseits haben unterschiedliche Fähigkeiten, Inhalte zu lesen. Die Maschine benötigt keinen Fettdruck, Farbspielereien, Leerzeilen und anderen Formatierungskram, dafür aber klare Zuordnungen (ID, Adresse, standardisierte Strukturen), um effizient zu arbeiten.
Wenn Du also keinen Code dafür verschwenden willst, Inhalte in einer "übersichtlichen" menschenlesbaren Darstellung zu suchen, dann verwende Speicherstrukturen, die unmittelbar verwendbar sind.

Beispiel: Wenn die ausgewählten Ziele als Minitabelle in Spalte G abgelegt werden, kannst Du unmittelbar ab G2 (bei Spaltentitel) mit dem Auslesen beginnen und hast somit die vermisste "feste" Zelladresse.

... und mit einem Löschen ab Zeile zwei übersichtlich umsetzbar.


Nachtrag:
Code:

Zur Codekürze inklusive -lesbarkeit und -pflegbarkeit gehört dann auch, dass man solche Passagen nicht laufend wiederholt, sondern per Refactoring in eigene Prozeduren auslagert und über passende Parametrisierung variabel aufruft.

 

Ich war da gedanklich bei einer Codezeile pro Control, aber da lag ich wohl falsch. Bin da dann noch nicht so fit in VBA wie ich es gern wäre.

Ich probiere den Mustercode mal aus, danke!

Da hast du absolut recht! War mein Fehler, dass ich nicht gesagt habe, dass ich dieses Tabellenblatt eben auch als übersichtlich lesbare Variante benötige.
Aber dann wäre es ja am sinnvollsten, wenn ich die UF zusätzlich noch in ein verstecktes Tabellenblatt maschinenlesbar auslese, mit der ich die UF später wieder fülle.

wie meinst du das?

Da hast du vollkommen Recht. habe tatsächlich einige Befehle in einen Sub oder eine Public Funktion ausgelagert, weil es echt unübersichtlich geworden ist, sobald man das mehr als 1x benötigt. Bei dem Befehl den du da ansprichst, hab ich es irgendwie nicht. Ich versuche mal mein Glück ob ich das hinbekomme. Bin da auch noch nicht so der Profi.