OptionValueManager

Diskussionen über den Quellcode (Module, Klassenstruktur, Schnittstellen u.s.w.) der Access Code Library

Re: OptionValueManager

Beitragvon Josef Pötzl » Mo 25. Mai 2015, 19:14

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
Josef Pötzl
Moderator
 
Beiträge: 805
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2016

Re: OptionValueManager

Beitragvon Andreas Vogt » Mo 25. Mai 2015, 19:23

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

Andreas
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Andreas Vogt » Mo 25. Mai 2015, 19:41

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
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Josef Pötzl » Mo 25. Mai 2015, 19:54

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
Josef Pötzl
Moderator
 
Beiträge: 805
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2016

Re: OptionValueManager

Beitragvon Andreas Vogt » Mo 25. Mai 2015, 20:32

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
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Josef Pötzl » Mo 25. Mai 2015, 20:45

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?
Josef Pötzl
Moderator
 
Beiträge: 805
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2016

Re: OptionValueManager

Beitragvon Andreas Vogt » Mo 25. Mai 2015, 20:51

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.
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Josef Pötzl » Mo 25. Mai 2015, 21:11

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.
Josef Pötzl
Moderator
 
Beiträge: 805
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2016

Re: OptionValueManager

Beitragvon Andreas Vogt » Di 26. Mai 2015, 09:10

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
Andreas Vogt
Entwickler
 
Beiträge: 165
Registriert: Do 18. Mär 2010, 18:00
Wohnort: Offenburg
Accessversion: 2.0, 97, 2002, 2003, 2007, 2010
Access-Erfahrung: Fortgeschritten

Re: OptionValueManager

Beitragvon Josef Pötzl » Di 26. Mai 2015, 09:25

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
Josef Pötzl
Moderator
 
Beiträge: 805
Registriert: Mo 30. Nov 2009, 10:08
Wohnort: Klagenfurt
Accessversion: 2016

VorherigeNächste

Zurück zu Quellcode

cron