<\/p>\n
Stücklisten dienen dazu, die Einzelteile eines Objekts strukturiert darzustellen. Strukturiert bedeutet dabei, dass die Einzelteile jeweils zu Baugruppen zusammengefasst werden. Ein Objekt besteht also aus Baugruppen und\/oder Einzelteilen, wobei jede Baugruppe wieder aus Baugruppen und\/oder Einzelteilen besteht – bis am Ende jede Baugruppe in ihre Einzelteile aufgelöst ist. Einzelteile sind die kleinsten Einheiten in der Stückliste, sie können nicht weiter aufgeteilt werden.Dieser Beitrag soll zeigen, wie Sie Stücklisten mit Access verwalten. Dabei spielt das TreeView-Steuerelement eine große Rolle.<\/b><\/p>\n
Die Stückliste kann dazu für verschiedene Zwecke genutzt werden: Sie können daraus zum Beispiel entnehmen, welche Mengen der verschiedenen Einzelteile benötigt werden. Dies ist sowohl für die Beschaffung der benötigten Einzelteile wichtig als auch für die Kalkulation der Materialkosten.<\/p>\n
Datenmodell<\/b><\/p>\n
Das Datenmodell der Lösung sieht im überblick wie in Bild 1 aus. Die Tabelle tblBaugruppen <\/b>enthält alle Baugruppen, für die in unserem einfach gehaltenen Ansatz nur der Name angegeben werden soll. Die Tabelle enthält lediglich die beiden Felder BaugruppeID <\/b>als Primärschlüsselfeld sowie das Feld Baugruppe <\/b>zur Eingabe einer Bezeichnung für die Baugruppe. Diese Tabelle kommt noch ein zweites Mal in der übersicht des Datenmodells vor. Dies hat den Hintergrund, dass Sie jeder Baugruppe weitere Baugruppen unterordnen können. Eine Baugruppe besteht ja nicht direkt lediglich aus Einzelteilen, sondern kann auch andere aus Einzelteilen oder auch Baugruppen zusammengesetzte Baugruppen enthalten.<\/p>\n
![\"übersicht](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_001.png\")
<\/p>\n
Bild 1: übersicht des Datenmodells für die Stückliste<\/span><\/b><\/p>\n Die Abbildung zeigt die Tabelle tblBaugruppen<\/b> ein zweites Mal, damit wir die Beziehung zwischen zwei Baugruppen abbilden können.<\/p>\n Verknüpfung zwischen Baugruppen<\/b><\/p>\n Dies geschieht nämlich durch die Verknüpfungstabelle tblBaugruppenzuordnungen<\/b> (s. Bild 2). Sie enthält die Felder BaugruppenzuordnungID (als Primärschlüsselfeld), BaugruppeVaterID <\/b>zur Angabe der übergeordneten Baugruppe aus der Tabelle tblBaugruppen<\/b>, das Feld BaugruppeKindID <\/b>zur Angabe der untergeordneten Baugruppe sowie das Feld Menge<\/b>.<\/p>\n Bild 2: Entwurf der Tabelle tblBaugruppenzuordnungen<\/span><\/b><\/p>\n Es kann ja auch sein, dass eine Baugruppe gleich mehrmals einer anderen Baugruppe zugeordnet werden soll (zum Beispiel vier Reifen zu einem Auto). Die gewünschte Anzahl tragen Sie dann in das Feld Menge <\/b>ein.<\/p>\n Für dieses Feld legen wir außerdem den Wert 1 <\/b>als Standardwert fest – dieser muss dann beim Anlegen gegebenenfalls angepasst werden.<\/p>\n Außerdem soll die Tabellen einen aus den beiden Feldern BaugruppeVaterID <\/b>und BaugruppeKindID <\/b>zusammengesetzten eindeutigen Index besitzen. Auf diese Weise verhindern wir, dass eine Kombination aus zwei Baugruppen mehrfach angelegt wird – zu diesem Zweck haben wir ja das Feld Menge hinzugefügt.<\/p>\n Weiter im Datenmodell: Neben den Baugruppen gibt es eine Tabelle mit den Daten der Einzelteile. Sie heißt tblEinzelteile <\/b>und ist in Bild 3 abgebildet.<\/p>\n Bild 3: Entwurf der Tabelle tblEinzelteile<\/span><\/b><\/p>\n Wo sind die Projekte<\/b><\/p>\n Irgendwann führen alle Baugruppen und\/oder Einzelteile zu einem vollständigen Projekt oder Produkt. Warum also gibt es in der Datenbank keine Tabelle für solche Elemente Wenn Sie möchten, können Sie natürlich eine solche hinzufügen. Allerdings ist schon jede einzelne Baugruppe ein Produkt für sich, und eigentlich auch jedes Einzelteil. Machen wir es uns also einfach und fügen einfach den beiden Tabellen tblBaugruppen<\/b> und tblEinzelteile <\/b>ein Ja\/Nein<\/b>-Feld namens IstProdukt <\/b>hinzu, mit dem Sie festlegen können, ob ein solches Element nicht nur Bestandteil einer Baugruppe sein kann, sondern gleichzeitig ein Produkt. Wozu aber benötigen wir solche eine Unterscheidung Weil wir auf irgendeine Weise kennzeichnen wollen, welche Elemente als Hauptelemente im TreeView zur Darstellung des Aufbaus von Bauteilen dienen sollen.<\/p>\n Beziehung zwischen Baugruppen und Einzelteilen<\/b><\/p>\n Um die Einzelteile den Baugruppen zuzuordnen, benötigen wir wiederum eine Verknüpfungstabelle zur Herstellung einer m:n-Beziehung. Diese heißt tblBaugruppenEinzelteile <\/b>und enthält das Primärschlüsselfeld BaugruppeEinzelteilID<\/b>, das Fremdschlüsselfeld BaugruppeID <\/b>zum Festlegen der Baugruppe aus der Tabelle tblBaugruppen<\/b>, das Fremdschlüsselfeld EinzelteilID <\/b>zum Festlegen des Einzelteils aus der Tabelle tblEinzelteile <\/b>und das Feld Menge <\/b>zur Angabe der Anzahl der Einzelteile.<\/p>\n Auch für das Feld Menge <\/b>dieser Tabelle stellen wir 1 <\/b>als Standardwert <\/b>ein, außerdem legen wir für die beiden Felder BaugruppeID <\/b>und EinzelteilID <\/b>einen zusammengesetzten, eindeutigen Index fest (s. Bild 4).<\/p>\n Bild 4: Entwurf der Tabelle tblBaugruppenEinzelteile<\/span><\/b><\/p>\n Die Tabelle tblEinzelteilKategorien <\/b>schließlich enthält verschiedene Kategorien für die Einzelteile. Diese Tabelle hat den Hinterrgrund, dass vielleicht später einmal die Einzelteile verschiedener Kategorien unterschiedlich rabattiert werden – gegebenenfalls auch noch in Abhängigkeit vom jeweiligen Kunden. Die Tabelle enthält die beiden Felder EinzelteilKategorieID <\/b>(als Primärschlüsselfeld) und Einzelteilkategorie<\/b>.<\/p>\n Die Tabelle tblEinzelteile <\/b>ist über das Feld EinzelteilkategorieID <\/b>mit dieser Tabelle verknüpft.<\/p>\n Darstellung der Baugruppen und Einzelteile<\/b><\/p>\n Die Lösung soll verschiedene Darstellungen ermöglichen. Zunächst einmal wollen wir eine einfache Möglichkeit zur Eingabe der Einzelteile schaffen. Dazu legen Sie ein neues Formular namens frmEinzelteile <\/b>an, das ein Unterformular sfmEinzelteile <\/b>enthält. Das Unterformular soll alle Einzelteile enthalten, das Hauptformular das aktuell im Unterformular ausgewählte Einzelteil. Das Unterformular statten wir außerdem mit einer Möglichkeit zum Filtern nach verschiedenen Kriterien aus.<\/p>\n In der Entwurfsansicht sieht das Unterformular wie in Bild 5 aus. Das Feld EinzelteilkategorieID <\/b>haben wir über den Kontextmenü-Eintrag ändern zu|Kombinationsfeld <\/b>in ein Kombinationsfeld umgewandelt, damit die Einträge der Tabelle tblEinzelteilkategorien <\/b>direkt nachgeschlagen werden können. Dazu haben wir die Eigenschaft Datensatzherkunft <\/b>auf den folgenden Ausdruck eingestellt:<\/p>\n Bild 5: Aufbau des Unterformulars sfmEinzelteile<\/span><\/b><\/p>\n Die Eigenschaften Spaltenanzahl <\/b>und Spaltenbreiten <\/b>erhalten die Werte 2 <\/b>und 0cm<\/b>. Das Formular erhält für die Eigenschaft Standardansicht <\/b>den Wert Datenblatt<\/b>.<\/p>\n Haupt- und Unterformular synchronisieren<\/b><\/p>\n Damit Haupt- und Unterformular die gleichen Datensätze markieren, muss beim Laden des Hauptformulars die folgende Prozedur ausgeführt werden. Diese stellt das Recordset des Hauptformulars auf das Recordset des Unterformulars ein:<\/p>\n Einzelteilkategorie auswählen<\/b><\/p>\n Damit neben der Auswahl der Datensätze der Tabelle tblEinzelteilkategorien <\/b>im Hauptformular nicht nur die bestehenden Einträge gewählt, sondern auch direkt neue Einträge eingefügt werden können, fügen Sie dem Kombinationsfeld eine Prozedur hinzu, die durch das Ereignis Bei nicht in Liste <\/b>ausgelöst wird (s. Listing 1).<\/p>\n Listing 1: Hinzufügen neuer Einträge in die Tabelle tblEinzelteilkategorien über das Kombinationsfeld<\/span><\/b><\/p>\n Diese Prozedur fragt den Benutzer bei der Eingabe eines noch nicht vorhandenen Wertes, ob ein neuer Eintrag in der Tabelle tblEinzelteilkategorien <\/b>angelegt werden soll. Falls ja, legt die Prozedur den Datensatz gleich mit einer entsprechenden SQL-INSERT INTO<\/b>-Anweisung an. Auf diese Weise sparen wir uns an dieser Stelle ein extra Formular für die Verwaltung der Kategorien (dieses würde notwendig, wenn Sie einmal Kategorien ändern oder löschen wollen). <\/p>\n Baugruppen verwalten<\/b><\/p>\n Für die Verwaltung der Baugruppen wollen wir ein ähnliches Formular wie für die Einzelteile anlegen. Wir benötigen also wieder ein Hauptformular, diesmal namens frmBaugruppen<\/b>, sowie ein Unterformular namens sfmBaugruppen<\/b>.<\/p>\n Allerdings weist die Tabelle tblBaugruppen <\/b>im aktuellen Zustand mit Baugruppe <\/b>und IstProdukt <\/b>ohnehin nur zwei Felder mit Geschäftsdaten auf. Wir müssen also nicht unbedingt ein Hauptformular mit den Detaildaten und ein Unterformular mit einer Listenansicht erstellen. Eine Liste im Unterformular reicht völlig aus, das Hauptformular soll nur weitere Steuerelemente wie etwa die OK<\/b>-Schaltfläche nachliefern. Im Entwurf sieht das Formular wie in Bild 6 aus.<\/p>\n Bild 6: Haupt- und Unterformular zur Darstellung von Baugruppen<\/span><\/b><\/p>\n Wenn Sie nun in die Formularansicht des Formulars frmBaugruppen<\/b> wechseln, erwartet Sie der Anblick auf Bild 7.<\/p>\n Bild 7: Bearbeiten von Baugruppen in der Formularansicht mit einem Unterformular in der Datenblattansicht<\/span><\/b><\/p>\n Baugruppen und Einzelteile im TreeView<\/b><\/p>\n Nun wenden wir uns interessanteren Themen zu: zum Beispiel dem Formular frm-StuecklisteTreeView<\/b>, welches ein TreeView<\/b>-Steuerelement zur hierarchischen Anzeige der Baugruppen und Einzelteile enthält.<\/p>\n Statten Sie dazu ein neues Formular namens frmStuecklisteTreeView <\/b>zunächst mit einem TreeView<\/b>-Steuerelement namens ctlTreeView <\/b>sowie mit einer Schaltfläche namens cmdOK <\/b>aus.<\/p>\n Stellen Sie die Eigenschaften Horizontaler Anker <\/b>und Vertikaler Anker <\/b>für das TreeView<\/b>-Steuerelement jeweils auf Beide <\/b>ein (s. Bild 8). Für die Eigenschaft Vertikaler Anker <\/b>der Schaltfläche cmdOK <\/b>legen Sie den Wert Unten <\/b>fest.<\/p>\n Bild 8: Verankern des TreeView-Steuerelements, sodass es sowohl vertikal als auch horizontal angepasst wird<\/span><\/b><\/p>\n Auf diese Weise passen sich TreeView<\/b>-Steuerelement und Schaltfläche an die Ausmaße des Formulars an – allerdings stehen diese Eigenschaften erst ab Access 2007 zur Verfügung. Sollten Sie noch eine ältere Access-Version nutzen – dies wäre ein Grund zum Wechseln.<\/p>\n Legen Sie außerdem ein ImageList<\/b>-Steuerelement an, denn wir wollen die Einträge des TreeView<\/b>-Steuerelements mit entsprechenden Icons etwas aufhübschen. Dieses Steuerelement soll den Namen ctlImageList <\/b>erhalten.<\/p>\n ImageList-Steuerelement füllen<\/b><\/p>\n Das ImageList<\/b>-Steuerelement müssen wir zunächst mit den benötigten Bildern füllen. Wir benötigen eines für das Root-Element des TreeView<\/b>-Steuerelements, eines für ein Projekt – in diesem Fall ein Hierarchie-Icon, eines für eine Baugruppe (hier durch mehrere Zahnräder abgebildet) sowie ein Icon für ein Einzelteil, hier ein einzelnes Zahnrad. Damit diese wie in Bild 9 in das ImageList<\/b>-Steuerelement gelangen, fügen Sie entweder selbst geeignete Bilder hinzu oder erledigen dies per VBA-Code.<\/p>\n Bild 9: Hinzufügen der benötigten Icons für das TreeView-Steuerelement<\/span><\/b><\/p>\n In unserem Fall war das notwendig, da das ImageList<\/b>-Steuerelement nicht mit dem Bildformat zurechtkam. Also lesen wir die Bilder erst in ein StdPicture<\/b>-Objekt ein und speichern diese dann im ImageList<\/b>-Steuerelement.<\/p>\n Eine einfache Prozedur, um dies zu erledigen, finden Sie im Modul mdl-ImageListFuellen <\/b>beziehungsweise in Listing 2.<\/p>\n Listing 2: Prozedur zum Füllen des ImageList-Steuerelements mit Bilddateien<\/span><\/b><\/p>\n Der Aufruf dieser Prozedur sieht etwa wie folgt aus:<\/p>\n Die Prozedur erwartet den Namen des Formulars, in dem sich das ImageList<\/b>-Steuerelement befindet, sowie den Namen des ImageList<\/b>-Steuerelements als Parameter. Außerdem können Sie eine durch Kommata getrennte Liste der hinzuzufügenden Elemente angeben.<\/p>\n Die Prozedur ImageListFuellen <\/b>öffnet das Formular im Entwurf, referenziert das ImageList<\/b>-Steuerelement und durchläuft alle Elemente der Bilderliste. Dabei liest sie erst den Pfad in die Variable strImage <\/b>ein und ermittelt daraus den reinen Dateinamen ohne Verzeichnis und Dateiendung. Dann erstellt sie ein StdPicture<\/b>-Objekt auf Basis des in der Datei gespeicherten Bildes und fügt dieses mit der Add<\/b>-Methode der ListImages<\/b>-Auflistung in das ImageList<\/b>-Steuerelement ein. Schließlich schließt sie das Formular und speichert dieses gleichzeitig.<\/p>\n Achtung: Die per VBA hinzugefügten Bilder bleiben nur dauerhaft im ImageList<\/b>-Steuerelement erhalten, wenn die Prozedur das Formular in der Entwurfsansicht öffnet – in der Formularansicht gelingt dies nicht. Deswegen müssen zur Laufzeit hinzugefügte Bilder auch bei jedem öffnen des Formulars neu hinzugefügt werden – außer, Sie möchten das Formular zur Laufzeit in der Entwurfsansicht öffnen, was zum Beispiel mit der Runtime oder mit .mde\/.accde<\/b>-Datenbanken nicht möglich ist.<\/p>\n Laden des Formulars <\/b><\/p>\n Nun erstellen Sie eine Ereignisprozedur, die durch das Ereignis Beim Laden <\/b>des Formulars ausgelöst wird. Dieses soll die Eigenschaften des TreeView<\/b>-Steuerelements einstellen, das ImageList<\/b>-Steuerelement zuweisen und eine Prozedur aufrufen, die das TreeView<\/b>-Steuerelement mit den Daten füllt.<\/p>\n In Listing 3 finden Sie zunächst die Deklaration zweier Variablen zum Referenzieren der beiden Steuerelemente ctlTreeView <\/b>und ctlImageList<\/b>.<\/p>\n <\/p>\n Listing 3: Diese Prozedur passt das TreeView-Steuerelement an und startet den Füllvorgang.<\/span><\/b><\/p>\n Die durch das Ereignis Beim Laden <\/b>ausgelöste Ereignisprozedur Form_Load <\/b>füllt zunächst die beiden Variablen objTreeView <\/b>und objImageList <\/b>mit Verweisen auf die Object<\/b>-Eigenschaft der entsprechenden Steuerelemente. Dann stellt sie einige Eigenschaften des Treeview<\/b>-Steuerelements ein. Dies könnten Sie zwar auch über das Eigenschaftsfenster des TreeView<\/b>-Steuerelements erledigen. Wenn Sie dies allerdings per Code tun, können Sie die entsprechenden Anweisungen direkt für weitere TreeView<\/b>-Steuerelemente übernehmen und brauchen sich nicht durch das Eigenschaftsfenster zu klicken.<\/p>\n Schließlich ruft die Prozedur die Routine TreeViewFuellen <\/b>auf, welche die Elemente der entsprechenden Tabellen einliest.<\/p>\n Produkte im TreeView anzeigen<\/b><\/p>\n Weiter oben haben wir definiert, dass sowohl Baugruppen als auch Einzelteile als Produkte eingesetzt werden können. Die einzige Kennzeichnung, die Produkte von herkömmlichen Baugruppen und Einzelteilen unterscheidet, ist der Wert True <\/b>im Feld IstProdukt <\/b>der beiden Tabellen tblBaugruppen <\/b>und tblEinzelteile<\/b>. Auf diese Weise ermöglichen wir es auch, dass als komplette Produkte klassifizierte Baugruppen oder Einzelteile weiterhin als Elemente einer Baugruppe verwendet werden können.<\/p>\n Wir wollen nun in der Prozedur TreeViewFuellen <\/b>zunächst ein Root-Objekt namens Produkte <\/b>anlegen. Unterhalb dieses Objekts sollen alle Baugruppen und Einzelteile erscheinen, die als Produkt gekennzeichnet sind. Die Prozedur TreeViewFuellen <\/b>ruft dann für jedes Produkt die rekursive Routine TreeView-Fuellen_Rek <\/b>auf, welche die untergeordneten Baugruppen und Einzelteile einliest.<\/p>\n Die Prozedur TreeViewFuellen<\/b> erstellt zunächst ein Recordset auf Basis der Abfrage qryProdukte<\/b> (s. Listing 4). Diese ist jedoch keine herkömmliche SELECT<\/b>-Abfrage, sondern eine UNION<\/b>-Abfrage. Sie führt die Ergebnisse der gespeicherten Abfragen qryProdukteBaugruppen <\/b>und qryProdukteEinzelteile <\/b>zusammen.<\/p>\n Listing 4: Füllen der ersten und zweiten Ebene des TreeView-Steuerelements<\/span><\/b><\/p>\n Die Abfrage qryProdukteBaugruppen<\/b> sieht wie in Bild 10 aus, und liefert alle Datensätze der Tabelle tblBaugruppen<\/b>, deren Feld IstProdukt <\/b>den Wert True <\/b>aufweist.<\/p>\n Bild 10: Abfrage von Baugruppen, die auch als Produkt ausgezeichnet sind.<\/span><\/b><\/p>\n Ganz ähnlich ist die Abfrage qryPro-dukte-Einzelteile <\/b>aufgebaut (s. Bild 11). Allerdings liefert diese die Datensätze der Tabelle tblEinzelteile<\/b>, die als Produkt gekennzeichnet sind. Die UNION<\/b>-Abfrage qryProdukte<\/b> fasst die Inhalte beider Abfragen zusammen. Sie enthält den folgenden Code:<\/p>\n Bild 11: Abfrage der Einzelteile, die auch als Produkt ausgezeichnet sind.<\/span><\/b><\/p>\n Hier ist zu beachten, dass Sie den jeweiligen Feldern der beiden Tabellen per AS<\/b>-Schlüsselwort den gleichen Spaltennamen zuweisen müssen.<\/p>\n Zurück zur Prozedur TreeViewFuellen<\/b>: Diese erstellt nun zunächst das Root-Element mit der Bezeichnung Produkte <\/b>und dem Bild, das im ImageList<\/b>-Steuerelement unter dem Key <\/b>mit dem Wert home <\/b>gespeichert ist. Das neue Element erhält als Key <\/b>den Wert r0<\/b>. Außerdem stellt die Prozedur die Eigenschaft Expanded <\/b>auf True <\/b>ein, damit das Element immer aufgeklappt ist.<\/p>\n Nun fügt die Prozedur alle Elemente der Tabellen tblBaugruppen <\/b>und tblEinzelteile <\/b>zur zweiten Ebene des TreeView<\/b>-Steuerelements hinzu, die als Produkte gekennzeichnet sind. Dazu durchläuft sie alle Datensätze des Recordsets rstProdukte <\/b>und legt jeweils ein neues Node<\/b>-Element an. Das bereits vorhandene Element r0 <\/b>wird als übergeordnetes Element angegeben. Die Elemente selbst erhalten als Key<\/b>-Wert den Buchstaben p <\/b>(für Produkt) und den Wert des Primärschlüsselfeldes.<\/p>\n Keine eindeutigen Werte<\/b><\/p>\n Ups – das klappt ja gar nicht! Wir verwenden ja eine UNION<\/b>-Tabelle, die Daten aus zwei verschiedenen Tabellen zusammenführt. Da beide Tabellen Primärschlüsselwerte aus dem gleichen Zahlenbereich verwenden, wird es früher oder später geschehen, dass ein als Produkt gekennzeichnetes Bauteil und ein solches Einzelteil den gleichen Primärschlüsselwert aufweisen – was einen Fehler auslöst.<\/p>\n Und wenn man noch einen Schritt weiter denkt, fällt einem auf, dass ähnliche Probleme auch bei Hinzufügen der untergeordneten Elemente zu erwarten sind: Selbst wenn wir hier die Baugruppen jeweils mit dem Buchstaben b <\/b>und die Einzelteile mit dem Buchstaben e <\/b>als erstem Zeichen ausstatten und im übrigen den Primärschlüsselwert hinzufügen, sind doppelte Key<\/b>-Werte zu erwarten.<\/p>\n Der Grund ist, dass die Baugruppen und Einzelteile nicht nur einer, sondern auch mehreren Baugruppen zugeordnet werden können.<\/p>\n Wie aber erhalten wir eine eindeutige Bezeichnung der Elemente des TreeView<\/b>-Steuerelements Sie können natürlich den Key etwa mit einem GUID-Wert füllen. Allerdings wollen wir ja, wenn der Benutzer auf ein Element klickt, um beispielsweise dessen Details anzuzeigen oder ein Kontextmenü einzublenden, auch identifizieren, welches Element er soeben angeklickt hat. Und das gelingt nur, wenn wir den Primärschlüsselwert und einen Buchstaben als Kennzeichen der Herkunftstabelle im Key<\/b>-Wert unterbringen.<\/p>\n Dies gelingt im TreeView<\/b>-Steuerelement am einfachsten, indem wir dem Key<\/b>-Wert jeweils die Key<\/b>-Werte der übergeordneten Elemente voranstellen. Das Produkt auf Basis der Baugruppe mit dem Primärschlüsselwert 12 <\/b>würde also den Key<\/b>-Wert b12 <\/b>erhalten. Wenn die Baugruppe mit der ID 12 <\/b>nun etwa eine weitere Baugruppe mit der ID 24 <\/b>enthält, wird diese mit dem Key<\/b>-Wert b12|b24 <\/b>ausgezeichnet. Besteht diese Baugruppe aus den Einzelteilen 7 <\/b>und 14<\/b>, erhalten diese im TreeView<\/b>-Steuerelement die Key<\/b>-Werte b12|b24|e7 <\/b>und b12|b24|e14<\/b>.<\/p>\n Wenn wir dann etwa beim Anklicken eines Elements ermitteln wollen, um welches Element es sich handelt, müssen wir nur per Zeichenkettenfunktion den Teil hinter dem ersten Pipe-Zeichen (|<\/b>) von hinten ermitteln und dann anhand des Buchstabens die Herkunftstabelle und anhand der Zahl den Primärschlüsselwert ermitteln.<\/p>\n ändern wir also die UNION<\/b>-Abfrage so, dass diese den für den Key <\/b>zu verwendenden Buchstaben mitliefert. Für die Tabelle tblBaugruppen <\/b>fügen wir also das Feld “b“ AS Key <\/b>hinzu und für die Tabelle tblEinzelteile <\/b>das Feld “e“ AS Key<\/b>:<\/p>\n Außerdem passen Sie die Zeile zum Hinzufügen der Produkte zum TreeView<\/b>-Steuerelement wie folgt an – statt dem fixen Key<\/b>-Buchstaben p <\/b>verwenden wir den Wert des Feldes rst!Key<\/b>:<\/p>\n Wenn Sie das Formular nun öffnen, sieht das TreeView<\/b>-Steuerelement wie in Bild 12 aus.<\/p>\n Bild 12: Das TreeView-Steuerelement mit den ersten Elementen<\/span><\/b><\/p>\n Wie geht es weiter<\/b><\/p>\n Wir haben nun die ersten beiden Ebenen des TreeView<\/b>-Steuerelements gefüllt. Nun ginge es eigentlich mit den weiteren Ebenen weiter – aber wir haben noch gar keine Daten für diese Ebenen eingegeben! Und um ehrlich zu sein: Ich erledige dies nur ungern, indem ich blindwütig Beispieldatensätze in die Tabellen eingebe. Besser, Sie nutzen dazu direkt die Beispielformulare. Mit Beispieldaten allein ist es hier aber nicht getan: Wir benötigen auch noch eine Möglichkeit, einem Produkt oder einer Baugruppe weitere Baugruppen oder Einzelteile unterzuordnen. Dies sollte der Benutzerfreundlichkeit halber direkt im TreeView<\/b>-Steuerelement geschehen.<\/p>\n Zur Steuerung der Elemente des TreeViews haben sich Kontextmenüs bewährt. Aber welche Kontextmenü-Einträge benötigen wir hier Normalerweise gibt es ja Befehle wie Element löschen<\/b>, Element bearbeiten <\/b>oder Element hinzufügen<\/b>. Auch hier benötigen wir diese Einträge, allerdings haben sie eine andere Bedeutung: Wenn Sie etwa den Kontextmenü-Eintrag Element löschen <\/b>einer Baugruppe verwenden, soll ja nicht der Baugruppen-Datensatz aus der Tabelle tblBaugruppen <\/b>gelöscht werden, sondern nur diese Baugruppe soll nicht mehr der übergeordneten Baugruppe oder dem Produkt untergeordnet sein – das heißt, wir entfernen lediglich einen Eintrag aus einer der Verknüpfungstabellen tblBaugruppenZuordnungen <\/b>oder tblBaugruppenEinzelteile<\/b>.<\/p>\n Das Gleiche gilt für das Hinzufügen: Wir wollen mit dem Eintrag Element hinzufügen <\/b>kein neues Element erzeugen, sondern nur eine der bestehenden Baugruppen oder Einzelteile zu einer Baugruppe hinzufügen.<\/p>\n Das eigentliche Hinzufügen, Bearbeiten oder Löschen von Baugruppen oder Einzelteilen sollte direkt in den beiden Formularen frmBaugruppen <\/b>oder frmEinzelteile<\/b> erfolgen.<\/p>\n Allerdings ist es natürlich schon sinnvoll, ein neues Element direkt vom Kontextmenü eines Node<\/b>-Elements aus anzulegen und dieses dann gleich als untergeordnetes Element zu übernehmen.<\/p>\n Da dies doch etwas komplizierter als gedacht ist, legen wir doch erst einmal einige wenige Beispieldatensätze in den Tabellen tblBaugruppen<\/b>, tblEinzelteile<\/b>, tblBaugruppenZuordnung <\/b>und tblEinzelteileBaugruppen <\/b>an.<\/p>\n Rekursives Füllen des TreeView-Steuerelements<\/b><\/p>\n Nun kümmern wir uns um das Füllen der darunter liegenden Ebenen. Dies erledigen wir mit der Prozedur TreeViewFuellen_Rek<\/b> (s. Listing 5). Sie erwartet als Parameter den Verweis auf das aktuelle Database<\/b>-Objekt sowie den Primärschlüsselwert des übergeordneten Elements und den Pfad des Elements – also die oben beschriebene, durch das Pipe-Zeichen getrennte Abfolge der Key<\/b>-Werte (zum Beispiel b1|b2|e6<\/b>).<\/p>\n Listing 5: Diese Prozedur füllt die untergeordneten Elemente und ruft sich selbst gegebenenfalls rekursiv auf.<\/span><\/b><\/p>\n Die Prozedur erstellt dann zunächst ein Recordset, das alle Datensätze einer Abfrage namens qryBaugruppenRek <\/b>enthält, deren Feld BaugruppeVaterID <\/b>den Primärschlüsselwert der übergeordneten Baugruppe im TreeView<\/b>-Steuerelement enthält. Die Abfrage qryBaugruppenRek <\/b>sieht wie in Bild 13 aus.<\/p>\n Bild 13: Die Abfrage qryBaugruppenRek liefert alle Baugruppen, die einer anderen Baugruppe untergeordnet sind.<\/span><\/b><\/p>\n Nach dem öffnen des Recordsets durchläuft die Prozedur eine Do While<\/b>-Schleife über alle darin enthaltenen Datensätze. Innerhalb der Schleife ermittelt die Prozedur zunächst den Key<\/b>-Buchstaben für das einzufügende Element, indem es die mit dem Parameter strPath <\/b>übergebene Zeichenkette um ein Pipe-Zeichen, den Buchstaben b <\/b>und den Primärschlüsselwert der abzubildenden Baugruppe ergänzt. Dann legt sie ein neues Node<\/b>-Element im TreeView<\/b>-Steuerelement an, wobei das Element unter dem Node<\/b>-Element mit strPath <\/b>übergebenen Key<\/b>-Wert angelegt wird. Als Key <\/b>verwendet die Prozedur den soeben ermittelten Wert aus strKey<\/b>, als Text <\/b>den Wert des Feldes Baugruppe <\/b>der zugrunde liegenden Abfrage.<\/p>\n Schließlich ruft die Prozedur für jedes neu angelegte Baugruppen-Element wieder die Prozedur TreeViewFuellen_Rek <\/b>auf und übergibt die entsprechenden Parameter.<\/p>\n Nachdem alle der mit lngID <\/b>bezeichneten Baugruppe untergeordneten Baugruppen angelegt sind, wendet die Prozedur sich den Einzelteilen zu. Auch für diese haben wir eine eigene Abfrage angelegt, die qryEinzelteileRek<\/b> heißt und in Bild 14 abgebildet ist. Mit einem weiteren Recordset referenziert die Prozedur alle Einträge dieser Abfrage, deren Feld BaugruppeID <\/b>(das aus der Verknüpfungstabelle tblEinzelteileBaugruppe <\/b>stammt) den mit dem Parameter lngID <\/b>übergebenen Wert enthält.<\/p>\n Bild 14: Die Abfrage qryEinzelteileRek liefert alle Einzelteile, die einer Baugruppe untergeordnet sind.<\/span><\/b><\/p>\n Auch hier durchläuft die Prozedur eine Do While<\/b>-Schleife über alle Datensätze und legt in ähnlicher Weise wie bei den Baugruppen die entsprechenden Node<\/b>-Elemente an. Die Unterschiede sind, dass zur Ergänzung des Key<\/b>-Wertes nicht der Buchstabe b <\/b>(für Bauteil), sondern e <\/b>(für Einzelteil) an den mit strPath <\/b>übergebenen Key<\/b>-Wert des übergeordneten Elements verwendet wird.<\/p>\n Außerdem verwendet die Add<\/b>-Methode der Nodes<\/b>-Auflistung hier den Namen eines anderen Bildes aus dem ImageList<\/b>-Steuerelement, nämlich gearwheel<\/b>.<\/p>\n Schließlich ist beim Anlegen der Node<\/b>-Elemente für die Einzelteile kein weiterer Aufruf der TreeViewFuellen_Rek<\/b>-Methode nötig, denn ein Einzelteil soll ja im Gegensatz zu einer Baugruppe nicht aus weiteren Einzelteilen bestehen. Das Ergebnis sieht schließlich wie in Bild 15 aus.<\/p>\n Bild 15: Die Baugruppen und Einzelteile werden korrekt eingelesen und angezeigt.<\/span><\/b><\/p>\n Kontextmenüs des TreeView-Steuerelements<\/b><\/p>\n Als Nächstes wollen wir Kontextmenüs zum TreeView<\/b>-Steuerelement hinzufügen. Dazu überlegen wir zunächst, welche Einträge wir für welche Elemente benötigen. Für das Root-Element brauchen wir:<\/p>\n Der Benutzer soll also sowohl neue als auch vorhandene Baugruppen und Einzelteile in der obersten Ebene anlegen können.<\/p>\n Für die Baugruppen (sowohl die in der obersten Ebene, also die Produkte auf Basis von Baugruppen) sollen folgende Kontextmenü-Einträge vorgesehen werden:<\/p>\n Die ersten drei Einträge sind selbsterklärend, die übrigen entsprechen denen für das Root-Element.<\/p>\n Für ein Einzelteil-Element soll das Kontextmenü folgende Einträge bereithalten:<\/p>\n Ereignis bei Rechtsklick implementieren<\/b><\/p>\n Im TreeView<\/b>-Steuerelement rufen wir ein Kontextmenü hervor, indem wir das Ereignis Bei Maustaste ab <\/b>des TreeView<\/b>-Steuerelements implementieren.<\/p>\n Die Ereignisprozedur aus Listing 6 liefert mit dem Button<\/b>-Parameter einen Wert, mit dem wir ermitteln können, welche Maustaste der Benutzer soeben gedrückt hat. In diesem Fall gleichen wir den Wert mit der Konstanten acRightButton <\/b>ab. Auch die beiden Parameter x <\/b>und y<\/b> des Prozeduraufrufs können wir verwenden, und zwar gleich in der folgenden Anweisung: Dort ermitteln wir mit der HitTest<\/b>-Methode des TreeView<\/b>-Steuerelements, welches Node<\/b>-Objekt sich an der mit x <\/b>und y <\/b>markierten Position befindet, und speichern einen Verweis darauf in der Variablen objNode<\/b>. Sollte der Benutzer auf einen der Einträge geklickt haben und nicht in den leeren Bereich des TreeView<\/b>-Steuerelements, ergibt ![\"Entwurf](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_002.png\")
<\/p>\n![\"Entwurf](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_003.png\")
<\/p>\n![\"Entwurf](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_004.png\")
<\/p>\n![\"Aufbau](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_005.png\")
<\/p>\nSELECT EinzelteilkategorieID, Einzelteilkategorie FROM tblEinzelteilkategorien \r\nORDER BY Einzelteilkategorie;<\/pre>\n
Private Sub <\/span>Form_Load()\r\n Set<\/span> Me.Recordset = Me!sfmEinzelteile.Form.Recordset\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>cboEinzelteilkategorieID_NotInList(NewData As String<\/span>, Response As Integer<\/span>)\r\n Dim <\/span>db As <\/span>DAO.Database\r\n If <\/span>MsgBox<\/span>(\"Kategorie ''\" & NewData & \"'' anlegen\", vbYesNo) = vbYes Then<\/span>\r\n Set<\/span> db = CurrentDb\r\n db.Execute \"INSERT INTO tblEinzelteilkategorien(Einzelteilkategorie) VALUES(''\" \r\n & NewData & \"'')\", dbFailOnError\r\n Response = acDataErrAdded\r\n End If<\/span>\r\nEnd Sub<\/span><\/pre>\n![\"Haupt-](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_006.png\")
<\/p>\n![\"Bearbeiten](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_007.png\")
<\/p>\n![\"Verankern](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_008.png\")
<\/p>\n![\"Hinzufügen](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_009.png\")
<\/p>\nPublic Sub <\/span>ImageListFuellen(strFormular As String<\/span>, strImageList As String<\/span>, _\r\n ParamArray strImages() As Variant<\/span>)\r\n Dim <\/span>objPicture As <\/span>stdole.StdPicture\r\n Dim <\/span>strImage As String<\/span>\r\n Dim <\/span>strImageName As String<\/span>\r\n Dim <\/span>objNode As <\/span>MSComctlLib.Node\r\n Dim <\/span>objImageList As <\/span>MSComctlLib.ImageList\r\n Dim <\/span>i As Integer<\/span>\r\n Dim <\/span>frm As <\/span>Form\r\n DoCmd.OpenForm strFormular, acDesign\r\n Set<\/span> frm = Forms(strFormular)\r\n Set<\/span> objImageList = frm(strImageList).Object\r\n For i = LBound<\/span>(strImages) To UBound<\/span>(strImages)\r\n strImage = strImages(i)\r\n strImageName = Mid<\/span>(strImage, InStrRev<\/span>(strImage, \"\\\") + 1)\r\n strImageName = Left<\/span>(strImageName, InStrRev<\/span>(strImageName, \".\") - 1)\r\n Set<\/span> objPicture = mdlOGL0713.LoadPictureGDIP(strImage)\r\n objImageList.ListImages.Add , strImageName, objPicture\r\n Next<\/span> i\r\n DoCmd.Close acForm, frm.Name\r\nEnd Sub<\/span><\/pre>\nImageListFuellen \"frmStuecklisteTreeView\", \"ctlImageList\", \"c:\\gearwheel.png\", _\r\n\"c:\\gearwheels.png\", \"c:\\home.png\", \"c:\\elements_hierarchy.png\"<\/pre>\n
Dim <\/span>WithEvents objTreeView As <\/span>MSComctlLib.TreeView\r\nDim <\/span>objImageList As <\/span>MSComctlLib.ImageList\r\nPrivate Sub <\/span>Form_Load()\r\n Set<\/span> objTreeView = Me!ctlTreeView.Object\r\n Set<\/span> objImageList = Me!ctlImageList.Object\r\n With<\/span> objTreeView\r\n .Appearance = ccFlat\r\n .BorderStyle = ccNone\r\n .ImageList = objImageList\r\n .LineStyle = tvwTreeLines\r\n .OLEDragMode = ccOLEDragAutomatic\r\n .OLEDropMode = ccOLEDropManual\r\n .Style = tvwTreelinesPlusMinusPictureText\r\n End With<\/span>\r\n TreeViewFuellen\r\nEnd Sub<\/span><\/pre>\nPrivate Sub <\/span>TreeViewFuellen()\r\n Dim <\/span>db As <\/span>DAO.Database\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>objNode As <\/span>MSComctlLib.Node\r\n Set<\/span> db = CurrentDb\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM qryProdukte\", dbOpenDynaset)\r\n objTreeView.Nodes.Clear\r\n Set<\/span> objNode = objTreeView.Nodes.Add(, , \"r0\", \"Produkte\", \"home\")\r\n With<\/span> objNode\r\n .Expanded = True<\/span>\r\n End With<\/span>\r\n Do While<\/span> Not<\/span> rst.EOF\r\n Set<\/span> objNode = objTreeView.Nodes.Add(\"r0\", tvwChild, \"r0|\" & rst!Key _\r\n & rst!ProduktID, rst!Produkt, \"elements_hierarchy\")\r\n If <\/span>rst!Key = \"b\" Then<\/span>\r\n TreeViewFuellen_Rek db, rst!ProduktID, objNode.Key\r\n End If<\/span>\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\nEnd Sub<\/span><\/pre>\n![\"Abfrage](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_010.png\")
<\/p>\n![\"Abfrage](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_011.png\")
<\/p>\nSELECT BaugruppeID AS ProduktID, Baugruppe AS Produkt\r\nFROM qryProdukteBaugruppen\r\nUNION\r\nSELECT EinzelteilID AS ProduktID, Einzelteil AS Produkt\r\nFROM qryProdukteEinzelteile\r\nORDER BY Produkt;<\/pre>\n
SELECT BaugruppeID AS ProduktID, Baugruppe AS Produkt, \r\n''b'' AS Key FROM qryProdukteBaugruppen\r\nUNION \r\nSELECT EinzelteilID AS ProduktID, Einzelteil AS Produkt, ''e'' AS Key\r\nFROM qryProdukteEinzelteile ORDER BY Produkt;<\/pre>\n
Set<\/span> objNode = objTreeView.Nodes.Add\r\n(\"r0\", tvwChild, rst!Key & rst!ProduktID, rst!Produkt, \"elements_hierarchy\")<\/pre>\n![\"Das](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_012.png\")
<\/p>\nPrivate Sub <\/span>TreeViewFuellen_Rek(db As <\/span>DAO.Database, lngID As Long<\/span>, strPath As String<\/span>)\r\n Dim <\/span>rst As <\/span>DAO.Recordset\r\n Dim <\/span>objNode As <\/span>MSComctlLib.Node\r\n Dim <\/span>strKey As String<\/span>\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM qryBaugruppenRek WHERE BaugruppeVaterID = " _\r\n & lngID, dbOpenDynaset)\r\n Do While<\/span> Not<\/span> rst.EOF\r\n strKey = strPath & \"|b\" & rst!BaugruppeID\r\n Set<\/span> objNode = objTreeView.Nodes.Add(strPath, tvwChild, strKey, _\r\n rst!Baugruppe, \"gearwheels\")\r\n TreeViewFuellen_Rek db, rst!BaugruppeID, strKey\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\n Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM qryEinzelteileRek " _\r\n & "WHERE qryEinzelteileRek.BaugruppeID = \" & lngID, dbOpenDynaset)\r\n Do While<\/span> Not<\/span> rst.EOF\r\n strKey = strPath & \"|e\" & rst!EinzelteilID\r\n Set<\/span> objNode = objTreeView.Nodes.Add(strPath, tvwChild, strPath & \"|e\" _\r\n & rst!EinzelteilID, rst!Einzelteil, \"gearwheel\")\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\nEnd Sub<\/span><\/pre>\n![\"Die](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_013.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_014.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2014_01\/pic_923_015.png\")
<\/p>\n\n
\n
\n