OptionValueManager

[Josef Pötzl]

Außerdem hab ich noch ne Frage. Warum hast du in das Klassenmodul die DAO-Referenz eingefügt?
Bedeutet das dass bei dem Import im AccessProjekt ein Verweiss gesetzt wird wenn nicht vorhanden?

Ja, der wird gesetzt, wenn er noch nicht vorhanden ist.

Das mit dem Einfügen und nicht sofort speichern, falls nicht kompiliert werden kann, sehe ich nicht so kritisch. Wer aus der Codelib etwas importiert und vorher seinen Code nicht kompilieren kann, muss sich einfach damit abfinden, dass er die Codemodule erstmal nur im VBA-Editor sieht.

LG
Josef

[Andreas Vogt]

OK, so lassen wir es, ich änder es gleich ab.

Andreas

[Andreas Vogt]

Hallo Josef,
da kommt mir grad eine Idee, sollte man nicht noch in die Klasse öffentliche Methoden einfügen um in der Tabelle Optionswerte einzufügen Optionswerte zu ändern oder Optionswerte zu löschen?
Damit braucht sich der User nicht darum zu kümmern wie die Tabelle heißt, oder wie man das Execute Statement absetzt. Eliminiert sicherlich Fehler bei nicht so geübten Anwendern.

Was meinst du?
Andreas

[Josef Pötzl]

Das Anfügen könnte man eventuell direkt mit dem Ändern verbinden.
Wenn man

Code: Alles auswählen

OptionManager.SettingByName("Xyz") = "123"

verwendet, und Xyz nicht vorhanden ist, könnte man gleich einfügen - ansonsten wird geändert.

Macht es Sinn im "Helper-Modul" eine Konstante festzulegen, die den Standard-Tabellennamen definiert, falls bei der Verwendung des OptionManagers keiner angegeben wurde?
Dann wären im Prinzip zwei Varianten möglich:
1. Wem der Tabellenname egal ist und nur eine Tabelle verwendet, lässt bzw. stellt den Namen im Modul ein und muss sich um sonst nichts mehr kümmern
2. Wer lieber den Tabellennamen bei jedem Anwendungstart festlegen will bzw. mehrere Instanzen mit unterschiedlichen Tabellen nutzen will, kann das über die Property einstellen.

Eine Bitte hätte ich noch:
Bitte ltOptions umbenennen. Das ist im Anwendungscode ein Public-Enum und man erkennt am Namen nicht, wozu die Aufzählung gut ist.

BTW:
Ich werde einmal ein paar Tests für die Klasse gestalten, dann kann man damit auch gleich die Verwendung zeigen.

LG
Josef

[Andreas Vogt]

Alles klar, werde das einbauen.
Entsprechend wäre der Aufruf für das Entfernen eines Optionswertes:

Code: Alles auswählen

OptionManager.DeleteByName "Xyz"

Oder?

Andreas

[Josef Pötzl]

DeleteByName und eventuell Delete(Enum-Wert)? .. falls VBA "Delete" als Methodennamen zulässt.

Grundsätzlicher Gedanke:
Wie nennt man diese gespeicherten Werte eigentlich am besten?
Options, Settings oder Properties?
(Im Visual Studio werden diese Anwendungseinstellungen als "Settings" bezeichnet.)

Da die Klasse OptionValueManager heißt, müssten die damit verwalteten Werte eigentlich die OptionValues oder nur Values sein, oder?

[Andreas Vogt]

Ja, wenn die Klasse + Modul + Demoanwendungen mal steht, sollte man sich gedanken machen über die Benamsung
Mir gefällt es auch nicht.
Properties sind imo nicht geeignet wegen der Verwechslungs-Gefahr mit den VBA-Properties.
Den Begriff "Settings" find ich nicht schlecht.

[Josef Pötzl]

Ein passender Name ist vor den Beispielen (Tests) auch schon ganz praktisch, dann muss man später nicht alles umschreiben.

Vorab: "Settings" trifft auch meiner Meinung nach den Einsatzzweck ganz gut, da man damit die Anwendungseinstellungen u. ä. verwalten wird.

Wie könnte man die Klasse "OptionValueManager" besser bezeichnen?
* ApplicationSettings
* SettingsManager
* SettingsCollection
* SettingsContainer
* ???

Im Prinzip ist die Klasse so etwas ähnliches wie eine "Dictionary"-Klasse - allerdings mit der Erweiterung, dass die Werte auch in einer Tabelle gespeichert werden.

[Andreas Vogt]

Hallo Josef
So ein Mist aber auch, die Klassenvariable überlebt das CodeModule.DeleteLines in der Prozedur CreateEnum nicht.
Und damit ist auch die Property OptionTable nicht besetzt und das Array myOptions ist nicht definiert.

Einzige Lösung die mir einfällt ist im Formular die Klasse neu zu referenzieren, und den Tabellennamen neu zu übergeben.
Bei Class Initialize hab ich jetzt folgenden Code: If Not OptionTable = "" Then catchOptionValues

Und mit diesem Formular-Code funktioniert es dann:

Code: Alles auswählen

Option Explicit

Private myOpt As OptionManager

Private Sub Form_Load()
    Set myOpt = New OptionManager
    myOpt.OptionTable = "tabOptions"
End Sub

Private Sub Form_Unload(Cancel As Integer)
    Set myOpt = Nothing
End Sub

Private Sub cmdTest1_Click()
    With myOpt
        .SettingByName("Opt1") = "4711"                 'Zahl
       .SettingByName("Opt2") = "c:\user\public\test\" 'String
       .SettingByName("Opt3") = "-1"                   'ja/nein
       .Update
    End With
    cmdTest1.Enabled = False
End Sub

Private Sub cmdTest2_Click()
    If myOpt Is Nothing Then
        Set myOpt = New OptionManager
        myOpt.OptionTable = "tabOptions"
    End If
   
    With myOpt
        Me.txtOpt1 = .Settings(Opt1)
        Me.txtOpt2 = .Settings(Opt2)
        Me.chkOpt3.Value = .Settings(Opt3)
    End With
End Sub

Aber das ist doch Sch..., dass die Klasse mehrfach referenziert werden muss.
Andreas

[Josef Pötzl]

Ich sehe da kein Problem. Wenn man als Entwickler Code ändert, ist es nun einmal so, dass Instanzen und Variableninhalte weg sind.
Wer will, soll sich eine Factory-Prozedur schreiben oder nutzt wie schon erwähnt die "DefaultOptionTable"-Konstante. Über die VB_PredeclaredId-Einstellung kann man im Code direkt den Klassennamen verwenden, wenn man nur eine Instanz benötigt und muss sich somit nicht um das abspeichern der Instanz kümmern.

Bei Class Initialize hab ich jetzt folgenden Code: If Not OptionTable = "" Then catchOptionValues

Wie setzt du OptionTable vor der Initialisierung?

LG
Josef