<\/p>\n
André Minhorst, Duisburg<\/b><\/p>\n
VBA wird im Allgemeinen die Eigenschaft abgesprochen, eine objektorientierte Programmiersprache zu sein. Um diese Aussage zu untersuchen, müsste man erst einmal festlegen, ab wann eine Sprache objektorientiert ist und welche Eigenschaften für diese Bezeichnung vorhanden sein müssen. Lässt man einmal außen vor, dass Vererbung und Polymorphismus im VBA-Sprachgebrauch Fremdwörter sind, kann man VBA sicher als objektorientierte Sprache auffassen. Wie auch immer – im vorliegenden Beitrag erfahren Sie, wie Sie sich die objektorientierten Eigenschaften von VBA zu Nutze machen.<\/b><\/p>\n
Wer mit Access arbeitet und dabei VBA für die Entwicklung von Datenbankanwendungen verwendet, kann vermutlich mit Objekten verschiedenen Typs umgehen – wenn er auch vielleicht noch nie einen eigenen Objekttyp erstellt hat.<\/p>\n
Sicher hat jeder schon einmal ein Recordset via VBA geöffnet und auf die darin enthaltenen Methoden wie Open, MoveNext, AddNew, Update oder Close zugegriffen oder Informationen aus Eigenschaften wie RecordCount, EOF oder Filter verwendet. Beispiele dafür zeigt die Routine aus Quellcode 1, die eine auf der Tabelle tblKontakte basierende Datensatzgruppe öffnet und den Inhalt der einzelnen Datensätze ausgibt. Mit diesem Code erzeugt man unter anderem eine Instanz des Objekttyps Recordset, legt einige seiner Eigenschaften wie beispielsweise die Datenherkunft und die zugrunde liegende Verbindung fest und greift anschließend auf die so verfügbar gemachten Daten zu.<\/p>\n
Public Sub OpenRecordset()\n Dim cnn As ADODB.Connection\n Dim rst As ADODB.Recordset\n Set cnn = CurrentProject.Connection\n Set rst = New ADODB.Recordset\n rst.Open \"tblKontakte\", cnn, adOpenKeyset, _ adLockPessimistic\n Do While Not rst.EOF\n Debug.Print rst!KontaktID, rst!Vorname, _ rst!Nachname\n rst.MoveNext\n Loop\n rst.Close\n Set rst = Nothing\n Set cnn = Nothing\nEnd Sub<\/pre>\nQuellcode 1<\/b><\/p>\n
Eine weitere, ganz offensichtliche Objektart ist beispielsweise ein Formular – wie für ein Objekt üblich, verfügt es über Methoden, Eigenschaften und Ereignisse. Ein Formularobjekt kann wiederum Steuerelemente enthalten, die ebenfalls Objekttypen repräsentieren.<\/p>\n
Mit den in Access vorhandenen Objekttypen lässt sich jede Menge nützlicher Dinge anstellen. Ein wichtiger Aspekt dabei ist, dass die unterschiedlichen Objekttypen bestimmte Methoden, Eigenschaften und Ereignisse enthalten. Ein Objekt des Typs Recordset fasst beispielsweise eine Menge Funktionalität zusammen. Und das Beste daran ist, dass man sich gar nicht darum kümmern muss, was im Innern dieses Objekts passiert – es reicht völlig aus, dass man die Methoden, Eigenschaften und Ereignisse kennt. Wen interessiert denn schon, was intern alles abläuft, wenn man die Methode AddNew eines Recordset-Objekts aufruft Wichtig ist allein das Kennen der Schnittstelle und dass das Objekt die gewünschten Reaktionen und Ergebnisse auf die getätigten Eingaben liefert.<\/p>\n
Hinweis<\/h3>\n
Um keine Verwirrung bezüglich der hier verwendeten Begriffe aufkommen zu lassen, sollen folgende Definitionen gelten: Der Inhalt eines Klassenmoduls definiert eine Klasse. Eine Klasse wird auch Objekttyp genannt. Das Instanzieren einer Klasse beziehungsweise eines Objekttyps erzeugt ein Objekt. Auf das Objekt kann man in der Folge über die Objektvariable zugreifen. Das Klassenmodul enthält also einen Entwurf dessen, wie das Objekt sich verhalten soll. Dieser Entwurf besteht aus der Definition geeigneter Eigenschaften, Methoden und Ereignisse sowie der dahinter liegenden Funktionen. <\/p>\n
Nun bietet Access nur eine begrenzte Menge Objekttypen, die allerdings bereits viele Anforderungen abdecken. Genau genommen sind Art und Menge der Objekttypen gerade so bemessen, dass sie als vernünftige Grundlage für den Aufbau der jeweils individuell abzubildenden Geschäftsprozesse einer Anwendung dienen.<\/p>\n
Damit gibt es bereits einige gute Gründe, um eigene Objekttypen zu schaffen:<\/p>\n
Wie bereits oben erwähnt, ist einer der Vorteile der Verwendung von Objekttypen, dass man reelle Objekte und deren Eigenschaften in einer Einheit zusammenfassen kann, deren Methoden, Eigenschaften und Ereignisse über eine entsprechende Schnittstelle erreichbar sind. Unter VBA spricht man in diesem Zusammenhang von einem Klassenmodul.<\/p>\n
Als Beispiel für die Erläuterung des Aufbaus und der Verwendung von Objekttypen dient ein Kontakt. Er enthält bestimmte Informationen zu einer Person wie Vorname, Nachname, Geschlecht und Adressdaten. Um nicht nur die Verwendung von Eigenschaften, sondern auch den Einsatz von Methoden vorzustellen, erhält die Beispielobjektklasse zusätzlich eine Routine zur Ausgabe der Adressdaten in Form einer Anschrift.<\/p>\n
Die zu den nachfolgenden Beispielen gehörenden Objekte und Codes finden Sie in der Beispieldatenbank OOMitAccess.mdb für Access 2000 und höher auf der beiliegenden CD. <\/p>\n
Access stellt drei unterschiedliche Modularten zur Verfügung: die Klassenmodule von Formularen und Berichten, Standardmodule sowie Klassenmodule, die nicht an ein bestimmtes Objekt wie ein Formular oder einen Bericht gebunden sind. Die Klassenmodule von Formularen und Berichten sind prinzipiell mit den im Anschluss vorgestellten Klassenmodulen identisch; der einzige Unterschied ist, dass Letztere keine Oberfläche in Form eines Formulars oder Berichts enthalten.<\/p>\n
Um ein solches Klassenmodul zu erstellen, wählen Sie im VBA-Editor von Access den Menüeintrag Einfügen\/Klassenmodul aus. Daraufhin öffnet Access ein fast leeres neues Klassenmodul, das Sie am besten direkt unter dem gewünschten Namen speichern – beispielsweise clsKontakt. Wählen Sie den Namen eines Klassenmoduls immer so, dass er auch verrät, welches Objekt sich dahinter verbirgt – später werden Sie über diesen Namen auf diese Klasse zugreifen.<\/p>\n
Damit der Debugger sich meldet, wenn eine Variable nicht ordnungsgemäß deklariert ist, sollten Sie im Prozedurkopf die Anweisung Option Explicit hinzufügen. <\/p>\n
Die Eigenschaften eines Objekttyps speichert man in herkömmlicher Weise in Variablen. Die Zugriffsmöglichkeiten auf diese Variablen kann man allerdings wesentlich flexibler gestalten als in Prozeduren in Standardmodulen.<\/p>\n
Sie können eine Variable innerhalb eines Klassenmoduls natürlich als öffentlich zugänglich deklarieren, indem Sie etwa folgende Anweisung verwenden:<\/p>\n
Public Vorname As String<\/pre>\nDamit können Sie den Wert dieser Variablen von außen lesen und auch ändern, haben aber keinerlei Vorteile der in Klassenmodulen üblichen Art der Deklaration.<\/p>\n
Dort gibt es nämlich so genannte Property-Funktionen, über die man von außen den Wert einer Variablen lesen und ändern kann. Daher deklariert man Variablen in Klassenmodulen niemals als öffentlich, sondern immer als privat. Die Property-Funktionen erlauben nicht nur den schreibenden und lesenden Zugriff auf die privaten Variablen (wobei es für jede Zugriffsart eine eigene Funktion gibt), sondern man kann dort beliebige weitere Anweisungen unterbringen. Auf diese Weise lässt sich beispielsweise ein Zeiger setzen, der Informationen darüber enthält, ob sich eine Variable seit Erstellung der Objektinstanz geändert hat.<\/p>\n
Namenskonventionen<\/h3>\n
Die Variablen, die über Property-Funktionen für die Außenwelt erreichbar sein sollen, kennzeichnet man durch Voranstellen eines weiteren Buchstabens zum eigentlichen Variablennamen. Genau genommen wählt man einen Namen aus, unter dem die Variable nach außen erscheinen soll, wie beispielsweise Vorname, und nennt die Variable intern mVorname.<\/p>\n
Hinzufügen einer Variablen<\/h2>\n
Um eine bessere Vorstellung davon zu bekommen, was es mit diesen Property-Funktionen auf sich hat, fügen Sie der Klasse einfach eine Variable hinzu und erstellen zwei passende Property-Funktionen:<\/p>\n
Dim mVorname As String\nPublic Property Get Vorname() As String\n Vorname = mVorname\nEnd Property\nPublic Property Let Vorname(strVorname _ As String)\n mVorname = strVorname\nEnd Property<\/pre>\nTesten der Variablen<\/h2>\n
Zum Testen der Funktionsweise verwenden Sie eine Prozedur namens BeispielKontakt in einem beliebigen Standardmodul. Um die Klasse verfügbar zu machen, deklarieren Sie zunächst eine entsprechende Objektvariable:<\/p>\n
Public Sub KontaktBeispiel()\n Dim objKontakt As clsKontakt\n ''... weitere Anweisungen\nEnd Sub<\/pre>\nNach der Eingabe des Schlüsselwortes As erscheint die Liste aller verfügbaren Objekttypen, unter denen sich nun auch die neu erstellte Klasse befindet – wenn Sie also später mal eine ganze Menge eigener Objekttypen verwenden, müssen Sie sich noch nicht einmal mehr deren Namen genau merken.<\/p>\n
Anschließend erzeugen Sie eine Instanz dieses Objekttyps, die Sie in der Prozedur verwenden möchten:<\/p>\n
Set objKontakt = New clsKontakt<\/pre>\nSie könnten die ersten beiden Anweisungen auch zu einer einzigen Anweisung zusammenfassen:<\/p>\n
Dim objKontakt As New clsKontakt<\/pre>\nDadurch sparen Sie zwar eine Zeile, aber wenn Sie die Objektinstanz möglicherweise erst später benötigen oder es sich erst im Verlaufe der Prozedur herausstellt, ob Sie diese überhaupt brauchen, verschwenden Sie unter Umständen wertvolle Ressourcen.<\/p>\n
Damit auch alles seine Ordnung hat und Objekte nicht unnötig Speicherplatz belegen, obwohl sie nicht mehr benötigt werden, legen Sie vorsichtshalber jetzt schon die Anweisung zum Zerstören des Objektes an:<\/p>\n
Set objKontakt = Nothing<\/pre>\nDas ist zwar im vorliegenden Fall nicht unbedingt erforderlich, da das Objekt ohnehin nach Beenden der Prozedur zerstört wird, aber es ist programmiertechnisch sauberer. Die folgenden Beispielanweisungen fügen Sie natürlich vor dieser Anweisung ein, da sie sich sonst auf ein nicht mehr vorhandenes Objekt bezögen.<\/p>\n
Und nun geht“s an die Variable mVorname und deren Property-Prozeduren, die zusammen die les- und schreibbare Eigenschaft Vorname ergeben. Die folgende Anweisung setzt den Wert dieser Variablen auf den Wert Heinz:<\/p>\n
objKontakt.Vorname = \"Heinz\"<\/pre>\nDank Intellisense erscheint der Eigenschaftsname direkt nach der Eingabe des Punktes hinter objKontakt in der Liste der verfügbaren Eigenschaften, Methoden und Ereignisse dieses Objekts – bisher also allein auf weiter Flur (s. Abb. 1).<\/p>\n
<\/p>\n
<\/b><\/p>\n
Abb. 1: Intellisense vereinfacht den Zugriff auf Objekteigenschaften.<\/b><\/p>\n
Um zu überprüfen, ob die Zuweisung funktioniert, geben Sie mit nachfolgender Anweisung den Inhalt der Eigenschaft im Testfenster aus:<\/p>\n
Debug.Print objKontakt.Vorname<\/pre>\nWas ist passiert<\/h3>\n
über die Zuweisung der Zeichenkette an objKontakt.Vorname haben Sie die Property Let-Methode aufgerufen. Diese nimmt den übergebenen Wert über den Parameter strVorname entgegen und weist ihn der privaten Variablen mVorname zu.<\/p>\n
Bei der nachfolgenden Ausgabe läuft es umgekehrt: Die Propery Get-Prozedur ermittelt den Wert der Variablen mVorname und schickt ihn über die Eigenschaft Vorname zur Ausgabe.<\/p>\n
Hinweis<\/h3>\n
Vielleicht haben Sie den großen Vorteil dieser Vorgehensweise schon erkannt: Sie können mit Hilfe von Get- und Let-Prozeduren für eine Property festlegen, ob diese zum Lesen, Schreiben oder gar für beide Zugriffsarten verfügbar sein soll. <\/p>\n
Im Gleichschritt: Marsch!<\/h3>\n
Nachdem Sie sich von der Funktionsweise der Eigenschaft Vorname überzeugt haben, können Sie nun die Variablen für die weiteren Eigenschaften des Kontakts wie Nachname, Strasse, PLZ, Ort, Land und Unternehmen sowie die entsprechenden Property Let und Property Get-Prozeduren anlegen. Damit hätten Sie eine Klasse erzeugt, die wichtige Eigenschaften eines Kontaktes erhalten und wieder ausgeben kann.<\/p>\n
Die Ereignisse Initialize und Terminate<\/h2>\n
Klassenmodule stellen zwei eingebaute Ereigniseigenschaften zur Verfügung, die beim Erzeugen und beim Zerstören einer Objektinstanz ausgelöst werden.<\/p>\n
Um die entsprechenden Ereigniseigenschaften zu erzeugen, wählen Sie einfach im VBA-Editor im linken Kombinationsfeld den Eintrag Class und im rechten den Namen der gewünschten Ereignisprozedur aus (s. Abb. 2).<\/p>\n
<\/p>\n
<\/b><\/p>\n
Abb. 2: Erzeugen einer Ereignisprozedur einer Klasse<\/b><\/p>\n
Diese Eigenschaften können Sie beispielsweise verwenden, um beim Erzeugen der Objektinstanz Variablen auf bestimmte Startwerte oder Verweise auf andere Objekte zu setzen. Beim Zerstören einer Objektinstanz erledigt man mit der entsprechenden Ereignisprozedur notwendige Aufräumarbeiten.<\/p>\n
Verwenden von Enumerationen<\/h2>\n
Sicher kennen Sie die Möglichkeit, per Intellisense eine vordefinierte Konstante für einen Parameter auszuwählen. Das Gleiche ist auch mit den Eigenschaften einer Objektinstanz möglich. Um bei unserem Beispiel mit den Kontaktdaten zu bleiben, fügen wir diesem noch eine Eigenschaft namens Geschlecht hinzu. Dafür gibt es unter normalen Umständen nur zwei mögliche Einträge, deren Auswahl man dem Benutzer gerne abnimmt. Die passende Enumeration sieht folgendermaßen aus:<\/p>\n
Public Enum enumGeschlecht\n männlich\n weiblich\nEnd Enum<\/pre>\nDie Definition der entsprechenden Variablen sowie der Property Let- und Get-Prozeduren sieht wie folgt aus:<\/p>\n
Dim mGeschlecht As enumGeschlecht\nPublic Property Get Geschlecht() As enumGeschlecht\n Geschlecht = mGeschlecht\nEnd Property\nPublic Property Let Geschlecht(lngGeschlecht As enumGeschlecht)\n mGeschlecht = lngGeschlecht\nEnd Property<\/pre>\nEs gibt also prinzipiell keine Unterschiede zu herkömmlichen Datentypen, mit der Ausnahme, dass der Datentyp als Enumeration definiert wird.<\/p>\n
Hier sind zwei Dinge zu beachten: Beim Zugriff auf diese Objekteigenschaft stehen zwar die beiden Konstanten zur Verfügung (s. Abb. 3). Wenn man sich den ausgewählten Wert nachher ausgeben lässt, erhält man aber nicht den ausgewählten Ausdruck, sondern die dahinter stehende Konstante.<\/p>\n
Public Function Anschrift() As String\n Dim strAnschrift As String\n Dim strAnrede As String\n If mGeschlecht = männlich Then\n strAnrede = \"Herrn \"\n Else\n strAnrede = \"Frau \"\n End If\n If Not mUnternehmen = \"\" Then\n strAnschrift = strAnschrift & mUnternehmen & vbCrLf\n strAnschrift = strAnschrift & strAnrede & mVorname & \" \" & mNachname & vbCrLf\n Else\n strAnschrift = strAnschrift & strAnrede & vbCrLf\n strAnschrift = strAnschrift & mVorname & \" \" & strNachname & vbCrLf\n End If\n strAnschrift = strAnschrift & mStrasse & vbCrLf\n strAnschrift = strAnschrift & mPLZ & \" \" & mOrt & vbCrLf\n strAnschrift = strAnschrift & mLand\n Anschrift = strAnschrift\nEnd Function<\/pre>\nQuellcode 1<\/b><\/p>\n
Womit wir direkt beim zweiten Punkt wären: Man kann den einzelnen Teilen der Enumeration direkt entsprechende Zahlenwerte mitgeben oder diese wie in obigem Beispiel weglassen. In dem Fall nummeriert Access die Werte hinter den Einträgen bei 0 beginnend durch. Für ein wenig mehr Kontrolle sollten Sie also selbst entsprechende Werte vergeben, also etwa folgendermaßen:<\/p>\n
Public Enum enumGeschlecht\n Männlich = 1\n Weiblich = 2\nEnd Enum<\/pre>\n
<\/p>\n
<\/b><\/p>\n
Abb. 3: Enumerationen können die Auswahl von Konstanten vereinfachen.<\/b><\/p>\n
Methoden von Objekttypen<\/h2>\n
Was kann man nun mit einer Klasse anfangen, die es erlaubt, Eigenschaften eines Kontaktes einzugeben und wieder abzurufen Ein einfaches Beispiel ist das Zusammenstellen einer Anschrift aus den eingegebenen Daten und deren Ausgabe.<\/p>\n
Dazu legen Sie einfach die Prozedur aus Quellcode 1 im Klassenmodul clsKontakt an.<\/p>\n
Function oder Sub<\/h3>\n
Genau wie in anderen Modulen kann man auch die öffentlich zugänglichen Prozeduren in Klassenmodulen als Function oder Sub ausführen. Der einzige Unterschied ist, dass eine Function ein Ergebnis an die aufrufende Routine zurückliefert. Das ist im Falle des Zusammenstellens einer Anschrift aus Adressdaten natürlich sinnvoll.<\/p>\n
Alternativ könnte man natürlich auch eine Eigenschaft für den Objekttyp festlegen, der die fertige Anschrift enthält. Die Function könnte man dann in eine Sub-Prozedur umwandeln, die das Ergebnis in eine der Eigenschaft entsprechende Variable schreibt. Die aufrufende Routine würde dann das Zusammenstellen der Anschrift anstoßen und anschließend das Ergebnis aus der Objekteigenschaft Anschrift ermitteln. Das ist aber nicht sinnvoll, da sich so unter Umständen Redundanzen innerhalb der Klasse ergeben.<\/p>\n
Wenn die Anschrift einmal erzeugt ist und eine Eigenschaft wie beispielsweise der Vorname geändert wird, würden die Daten der Anschrift und der zugrunde liegenden Eigenschaften nicht mehr übereinstimmen. Man müsste dann schon die Property Let-Prozeduren jeder einzelnen Eigenschaft so anpassen, dass bei änderung einer Eigenschaft auch direkt die Anschrift neu zusammengestellt wird – und das wäre im vorliegenden Beispiel nicht sehr sinnvoll. Daher ist die Rückgabe des Ergebnisses als Funktionswert der bessere Weg.<\/p>\n
Public Sub KontaktBeispiel()\n Dim objKontakt As clsKontakt\n Set objKontakt = New clsKontakt\n With objKontakt\n .Vorname = \"Heinz\"\n .Nachname = \"Müller\"\n .Geschlecht = männlich\n .Strasse = \"Teststraße 12\"\n .PLZ = \"12345\"\n .Ort = \"Beispielstadt\"\n .Unternehmen = \"Müller''s \" _ & \"Klassenmodule\"\n MsgBox .Anschrift\n End With\n Set objKontakt = Nothing\nEnd Sub<\/pre>\nQuellcode 2<\/b><\/p>\n
<\/p>\n
<\/b><\/p>\n
Abb. 4: Ergebnis der Methode Anschrift des Klassenmoduls<\/b><\/p>\n
Die Anwendung der Funktion Anschrift des Klassenmoduls sieht nun wie in Quellcode 2 aus. Abb. 4 zeigt, wie die durch die Prozedur KontaktBeispiel erzeugte Anschrift aussieht.<\/p>\n
Funktionsparameter oder Objekteigenschaften<\/h3>\n
Eine weitere wichtige Frage, die sich gerade bei dem soeben beschriebenen Beispiel aufdrängt, ist folgende: Warum soll man eigentlich extra Eigenschaften erzeugen, um Werte zu übergeben, die man auch per Funktionsparameter übermitteln könnte Die Antwort für den vorliegenden Fall lautet: Im diesem Fall könnte man die benötigten Werte ebenso per Funktionsparameter übergeben. Der Grund dafür, dass wir dennoch für jeden Wert eine eigene Eigenschaft inklusive Property-Funktionen angelegt haben, ist der, dass der Objekttyp in den folgenden Beispielen noch um einige Funktionen erweitert werden soll, die die Verwendung der Eigenschaften rechtfertigen.<\/p>\n
Wenn eine Anwendung von verschiedenen Stellen aus auf in Tabellen gespeicherte Daten zugreift, enthält sie zwangsläufig Routinen mit immer gleichen oder zumindest ähnlichen Anweisungen für den Datenzugriff. Mit einer Klasse für den Zugriff auf die Daten einer Tabelle lassen sich derartige immer wiederkehrende Programmierarbeiten vereinfachen.<\/p>\n
Die nachfolgenden beiden Beispielprozeduren zeigen, wie Sie die Daten eines Objekts in eine Tabelle schreiben und von dort wieder einlesen können. Später erfahren Sie, wie Sie diese Prozeduren verwenden können, um ungebundene Formulare mit Daten zu füllen.<\/p>\n
Schreiben von Objektdaten in eine Tabelle<\/h2>\n
Die Routine aus Quellcode 3 schreibt die aktuellen Kontaktdaten in die Tabelle tblKontakte, die wie in Abb. 5 aufgebaut ist und alle Felder enthält, die auch in der Klasse clsKontakt als Eigenschaft vorhanden sind.<\/p>\n
Public Function Save() As Boolean\n Dim cnn As ADODB.Connection\n Dim rst As ADODB.Recordset\n Set cnn = CurrentProject.Connection\n Set rst = New ADODB.Recordset\n rst.Open \"SELECT * FROM tblKontakte WHERE \" _ & \"KontaktID = \" & mID, cnn, adOpenKeyset, _ adLockPessimistic\n With rst\n If .EOF Then\n .AddNew\n mID = !KontaktID\n End If\n !Vorname = mVorname\n !Nachname = mNachname\n !Geschlecht = mGeschlecht\n !Strasse = mStrasse\n !PLZ = mPLZ\n !Ort = mOrt\n !Land = mLand\n !Unternehmen = mUnternehmen\n .Update\n End With\n Save = True\nSave_Exit:\n rst.Close\n Set rst = Nothing\n Set cnn = Nothing\n Exit Function\nSave_Err:\n Save = False\n GoTo Save_Exit\nEnd Function<\/pre>\nQuellcode 3<\/b><\/p>\n
<\/p>\n
<\/b><\/p>\n
Abb. 5: Entwurfsansicht der Tabelle tblKontakte<\/b><\/p>\n
Die Routine erstellt erst die erforderlichen Connection- und Recordset-Instanzen. Das Recordset füllt sie mit allen Datensätzen der Tabelle tblKontakte, deren KontaktID dem in der Variablen mID gespeicherten Wert entspricht.<\/p>\n
Wenn ein solcher Datensatz noch nicht vorhanden ist, legt die Methode einen neuen Datensatz an und speichert die KontaktID des neuen Datensatzes in der Variablen mID der Klasse. <\/p>\n
Anschließend stellt sie die übrigen Felder der Tabelle auf die in den Objekteigenschaften gespeicherten Werte ein und aktualisiert die Tabelle. Die rudimentäre Fehlerbehandlung sorgt lediglich dafür, dass die Methode beim Auftreten eines Fehlers den Wert False als Funktionswert an die aufrufende Routine zurückgibt.<\/p>\n
Der Aufruf könnte wie in Quellcode 4 aussehen. Wie in den vorherigen Beispielen versieht auch diese Routine die einzelnen Eigenschaften mit entsprechenden Werten (in Quellcode 4 aus Platzgründen entfernt). Das Ergebnis des Aufrufs der Save-Methode des Objekts objKontakt wertet die Routine so aus, dass ein Meldungsfenster mit einer entsprechenden Nachricht den Erfolg oder das Scheitern des Speichervorgangs mitteilt.<\/p>\n
Einlesen von Daten in ein Objekt<\/h2>\n
Die Prozedur zum Einlesen eines Kontaktes aus der Tabelle tblKontakte in ein Objekt des Typs clsKontakt sieht wie in Quellcode 5 aus. Sie öffnet ein Recordset mit dem Datensatz, dessen KontaktID der ID des Objekts entspricht.<\/p>\n
Public Sub KontaktSpeichern()\n Dim objKontakt As clsKontakt\n Set objKontakt = New clsKontakt\n With objKontakt\n ''...Eigenschaftszuweisungen...\n If objKontakt.Save = True Then\n MsgBox \"Speichern erfolgreich!\"\n Else\n MsgBox \"Speichern missglückt!\"\n End If\n End With\n Set objKontakt = Nothing\nEnd Sub<\/pre>\nQuellcode 4<\/b><\/p>\n
Public Function Load() As Boolean\n Dim cnn As ADODB.Connection\n Dim rst As ADODB.Recordset\n Set cnn = CurrentProject.Connection\n Set rst = New ADODB.Recordset\n rst.Open \"SELECT * FROM tblKontakte WHERE \" _ & \"KontaktID = \" & mID, cnn, adOpenKeyset, _ adLockPessimistic\n With rst\n If Not .EOF Then\n mVorname = !Vorname\n mNachname = !Nachname\n mGeschlecht = !Geschlecht\n mStrasse = !Strasse\n mPLZ = !PLZ\n mOrt = !Ort\n mLand = !Land\n mUnternehmen = !Unternehmen\n Load = True\n Else\n Load = False\n End If\n End With\nLoad_Exit:\n rst.Close\n Set rst = Nothing\n Set cnn = Nothing\n Exit Function\nLoad_Err:\n Load = False\n GoTo Load_Exit\nEnd Function<\/pre>\nQuellcode 5<\/b><\/p>\n
Anders als in der Prozedur Save aus Quellcode 3 liest diese Prozedur die einzelnen Feldwerte der Tabelle in die Eigenschaften der Objektinstanz ein. Auch hier sorgt die Fehlerbehandlung dafür, dass die Funktion in jedem Fall eine Erfolgs- oder Misserfolgsmeldung zurückgibt.<\/p>\n
Der Aufruf dieser Methode erfolgt beispielsweise wie in der Prozedur aus Quellcode 6. Zu Beispielzwecken erfolgt ein „hartes“ Setzen der ID des gewünschten Datensatzes.<\/p>\n
Wenn die Load-Methode fündig wird, erscheint ein Meldungsfenster mit Vor- und Nachnamen des gesuchten Kontakts.<\/p>\n
Natürlich greifen Sie nicht immer nur von Prozeduren aus auf eine Klasse zu, die beispielsweise die Daten einer Tabelle kapselt. Um praktischen Nutzen aus der soeben erstellten Klasse zum Laden und Speichern eines Kontaktes zu ziehen, lernen Sie nachfolgend, wie Sie ein ungebundenes Formular zur Anzeige und zum Bearbeiten der gewünschten Kontaktdaten verwenden können. <\/p>\n
Abb. 6 zeigt das Formular in der Formularansicht. Alle Felder des Formulars sind ungebunden, nur die mit den beiden Kombinationsfeldern auswählbaren Informationen stammen aus den entsprechenden Tabellen.<\/p>\n
Dabei dient das Kombinationsfeld cboKontaktID zur Auswahl des anzuzeigenden Kontakts. <\/p>\n
<\/p>\n
<\/b><\/p>\n
Abb. 6: Ungebundenes Formular zur Anzeige von Kontaktdaten<\/b><\/p>\n
Vorteile von ungebundenenFormularen<\/h2>\n
Wenn Sie statt eines herkömmlichen, an eine Datenherkunft gebundenen Formulars ein ungebundenes Formular verwenden, das seine Daten aus einem Objekt bezieht, haben Sie mehrere Vorteile. Sie können beispielsweise viel genauer steuern, wann Daten in das Formular gelangen, wie Sie zwischen den vorhandenen Datensätzen navigieren oder wann die Daten gespeichert werden.<\/p>\n
Laden eines Kontaktes<\/h2>\n
Die Auswahl eines Eintrags des Kombinationsfeldes zur Anzeige der vorhandenen Kontakte löst die entsprechende Ereigniseigenschaft aus, die wiederum die Prozedur LoadKontakt startet.<\/p>\n
Diese Prozedur (s. Quellcode 7) erzeugt zunächst eine neue Instanz der Klasse clsKontakt und weist ihrer Eigenschaft ID die KontaktID des im Kombinationsfeld ausgewählten Eintrags zu.<\/p>\n
Mit dieser ID im Gepäck darf anschließend die Load-Methode des Kontakt-Objekts seinen Dienst verrichten; die so in die Klasse geladenen Daten landen direkt in den entsprechenden Feldern des Formulars.<\/p>\n
Public Sub KontaktLaden()\n Dim objKontakt As clsKontakt\n Set objKontakt = New clsKontakt\n With objKontakt\n .ID = 10\n If .Load = True Then\n MsgBox \"Vorname: \" _ & .Vorname & vbCrLf _ & \"Nachname: \" _ & .Nachname\n Else\n MsgBox \"Der Datensatz ist \" _ & \" nicht vorhanden.\"\n End If\n End With\n Set objKontakt = Nothing\nEnd Sub<\/pre>\nQuellcode 6<\/b><\/p>\n
Private Sub LoadKontakt()\n Dim objKontakt As clsKontakt\n Set objKontakt = New clsKontakt\n With objKontakt\n .ID = Me!cboKontaktID\n If .Load = True Then\n Me!txtVorname = .Vorname\n Me!txtNachname = .Nachname\n Me!cboGeschlechtID = _ .Geschlecht\n Me!txtStrasse = .Strasse\n Me!txtPLZ = .PLZ\n Me!txtOrt = .Ort\n Me!txtLand = .Land\n Me!txtUnternehmen = _ .Unternehmen\n Else\n MsgBox \"Kontakt kann \" _ & \"nicht angezeigt \" _ & \"werden.\"\n End If\n End With\nEnd Sub<\/pre>\nQuellcode 7<\/b><\/p>\n
Speichern eines Kontaktes<\/h2>\n
Ein Klick auf die Speichern-Schaltfläche des Formulars ruft über die entsprechende Ereigniseigenschaft die Prozedur SaveKontakt auf (s. Quellcode 8). Diese weist einer frisch erzeugten Instanz der Kontakt-Klasse die in den Feldern des Formulars enthaltenen Daten zu – inklusive der ID des aktuell im Kombinationsfeld ausgewählten Eintrags. Beim Scheitern des Speichervorgangs erscheint eine entsprechende Meldung, anderenfalls aktualisiert die Prozedur das Kombinationsfeld cboKontaktID und setzt es auf die ID des soeben gespeicherten Datensatzes. Das mag auf den ersten Blick unnötig erscheinen, ist es aber nicht – wie der nächste Abschnitt zeigen wird.<\/p>\n
Private Sub SaveKontakt()\n Dim objKontakt As clsKontakt\n Set objKontakt = New clsKontakt\n With objKontakt\n .ID = Me!cboKontaktID\n .Vorname = Me!txtVorname\n .Nachname = Me!txtNachname\n .Geschlecht = Me!cboGeschlechtID\n .Strasse = Me!txtStrasse\n .PLZ = Me!txtPLZ\n .Ort = Me!txtOrt\n .Land = Me!txtLand\n .Unternehmen = Me!txtUnternehmen\n If Not .Save = True Then\n MsgBox \"Speichern nicht \" _ & \"erfolgreich.\"\n Else\n Me!cboKontaktID.Requery\n Me!cboKontaktID = .ID\n End If\n End With\nEnd Sub<\/pre>\nQuellcode 8<\/b><\/p>\n
Anlegen eines neuen Kontakts<\/h2>\n
Die Schaltfläche cmdNeuerKontakt leert alle vorhandenen Felder des Formulars. Nach Eingabe der Daten des neuen Kontakts kann dieser mit der Prozedur aus Quellcode 8 gespeichert werden. Damit findet sich auch der Grund für die Aktualisierung des Kombinationsfeldes und die Zuweisung der aktuellen ID: Beim Speichern des neuen Datensatzes zeigt das Kombinationsfeld cboKontaktID keinen Wert an, weil der neue Kontakt ja noch nicht in der Tabelle verfügbar ist und er auch noch keine ID hat. Diese ist erst nach dem Speichern des Datensatzes bekannt. Daher kann (und muss) das Kombinationsfeld erst nach dem Speichern auf den neuen Wert eingestellt werden. Wenn das nicht passiert und man erneut die Speichern-Schaltfläche betätigt, speichert die Prozedur SaveKontakt den Kontakt erneut – in einem neuen Datensatz.<\/p>\n
Die hier vorgestellten Techniken sind eventuell nicht für die Quick-and-Dirty-Anwendung geeignet, die in einer halben Stunde programmiert werden und einen Tag halten soll. Wenn Sie aber den Wunsch verspüren, leicht zu wartende und auch von anderen Personen leicht erfassbaren Code zu erstellen, werden Sie bald von der Anwendung der Klassenmodule begeistert sein.<\/p>\n
Einige interessante Techniken lässt dieser Beitrag bewusst offen, da sich weitere Beiträge genauer damit beschäftigen – dazu gehört etwa die Verwendung des Collection-Objekts. Damit können Sie selbst Paare verknüpfter Tabellen abbilden, indem Sie zu jeder Tabelle einen passenden Objekttyp erstellen, von denen der eine Objekte des anderen Typs in einer Collection erfassen kann. Um dieses Thema geht es im Beitrag Relationale Verknüpfungen mit Objekten nachbilden in der der kommenden Ausgabe von Access im Unternehmen.<\/p>\n
Des Weiteren besteht die Möglichkeit, benutzerdefinierte Ereignisse für Objekte festzulegen – auch diese Eigenschaft beschreibt der vorliegende Beitrag nicht.<\/p>\n
Die Erzeugung von Objekttypen sollte äußerst sorgfältig erfolgen, da diese unter Umständen von vielen Stellen aus referenziert und gegebenenfalls auch in weiteren Anwendungen weiterverwendet werden sollen. Bei der Entwicklung ausgefeilter Klassen hilft eine spezielle Vorgehensweise – die so genannte Testgetriebene Entwicklung (aus dem Englischen: Test Driven Development, kurz: TDD). Dieser Methode widmet sich der Beitrag Testgetriebene Entwicklung mit Access, den Sie ebenfalls in dieser Ausgabe finden.<\/p>\n
Downloads zu diesem Beitrag<\/h2>\n
Enthaltene Beispieldateien:<\/p>\n
OOMitKlassen00.mdb<\/p>\n