{"id":55001331,"date":"2021-12-01T00:00:00","date_gmt":"2021-12-10T07:39:29","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=1331"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Ribbonvariable_fehlerresistent_machen","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Ribbonvariable_fehlerresistent_machen\/","title":{"rendered":"Ribbonvariable fehlerresistent machen"},"content":{"rendered":"

\"\"<\/p>\n

In VBA-Projekten von Access-Datenbanken (und in VBA im Allgemeinen) gibt es das Problem, dass das Auftreten von unbehandelten Laufzeitfehlern dazu führt, dass Objektvariablen geleert werden. Das ist insbesondere dann nachteilig, wenn Sie mit dem Ribbon arbeiten und dieses zwischendurch mit der Invalidate-Methode ungültig machen müssen, damit die Attribute mit get…-Prozeduren erneut eingelesen werden können. Der Aufruf von Invalidate führt dann unweigerlich zu einem Laufzeitfehler. Dieser Beitrag beschreibt das grundlegende Beispiel und liefert eine Lösung, mit der Sie sich keine Sorgen mehr um Objektvariablen machen müssen, die durch Laufzeitfehler geleert werden.<\/b><\/p>\n

Leeren von Objektvariablen nach Laufzeitfehlern reproduzieren<\/h2>\n

Als Erstes schauen wir uns an, mit welchem Problem wir es überhaupt zu tun haben. Das Problem betrifft nicht nur die Variablen, die in Zusammenhang mit dem Ribbon erstellt werden. Allerdings haben Objektvariablen üblicherweise eine überschaubare Gültigkeitsdauer – sie werden in der Regel innerhalb einer Prozedur deklariert und verlieren ihre Gültigkeit nach dem Beenden der Prozedur auch wieder.<\/p>\n

Grundsätzlich ist es ohnehin nicht empfehlenswert, mit global deklarierten Variablen zu arbeiten, da diese nicht nur von überall gelesen, sondern auch von überall geändert werden können. Dabei treten schnell Probleme auf, wenn man von mehreren Stellen aus auf solche Variablen zugreift und nicht genau weiß, was man da tut.<\/p>\n

Spätestens, wenn mal jemand anderer die Anwendung übernimmt und anpasst und sich nicht bewusst ist, das er dort mit global deklarierten Variablen arbeitet, könnte es zu Problemen kommen.<\/p>\n

Beispiel für Datenverlust nach Laufzeitfehlern<\/h2>\n

Schauen wir uns also zunächst einmal den grundsätzlichen Effekt an, um zu sehen, womit wir es zu tun haben. Dazu deklarieren wir in einem Standardmodul die folgende Variable:<\/p>\n

Public <\/span>db As <\/span>DAO.Database<\/pre>\n
db ist nun öffentlich deklariert und kann von überall innerhalb der Anwendung gesetzt und gelesen werden. Wir setzen diese in einer kleinen Prozedur im gleichen Modul:<\/p>\n
Public Sub <\/span>DbSetzen()\r\n     Set<\/span> db = CurrentDb\r\nEnd Sub<\/span><\/pre>\n
Wir können nun im Direktbereich von Access über die Objektvariable db auf das referenzierte Objekt zugreifen und so beispielsweise den Pfad der aktuellen Anwendung ermitteln:<\/p>\n
  db.Name\r\nC:\\Users\\...\\RibbonvariableFehlersicherMachen.accdb<\/pre>\n
Nun provozieren wir einen unbehandelten Laufzeitfehler, indem wir die folgende Prozedur auslösen:<\/p>\n
Public Sub <\/span>RaiseError()\r\n     Debug.Print<\/span> 1 \/ 0\r\nEnd Sub<\/span><\/pre>\n
Dies ruft die Fehlermeldung aus Bild 1 hervor. Klicken wir hier auf Beenden<\/b>, vervollständigen wir den unbehandelten Laufzeitfehler. Durch einen Klick auf Debuggen und gegebenenfalls Änderungen im Code könnten wir den Fehler behandeln, was wir aber an dieser Stelle nicht wollen. Stattdessen klicken wir schlicht auf Beenden<\/b>.<\/p>\n
\"Unbehandelter<\/p>\n
Bild 1: Unbehandelter Laufzeitfehler<\/span><\/b><\/p>\n
Dies führt zunächst einmal zu keiner sichtbaren Folge – davon abgesehen, dass die Prozedur an dieser Stelle einfach abgebrochen wird.<\/p>\n
Es gibt jedoch noch einen weiteren Nebeneffekt: Die Variable db <\/b>ist nun leer und zeigt nicht mehr auf das soeben referenzierte Objekt des Typs Database<\/b>. Wie können wir das herausfinden Indem wir einfach nochmal versuchen, den Pfad der aktuellen Anwendung im Direktbereich auszugeben.<\/p>\n
Dies führt nun zu dem Fehler aus Bild 2. Die Variable enthält also nicht mehr den Verweis auf das Database<\/b>-Objekt.<\/p>\n
\"Die<\/p>\n
Bild 2: Die Variable db ist geleert.<\/span><\/b><\/p>\n
Wozu globale Ribbonvariablen<\/h2>\n
Doch zurück zur eigentlichen Problemstellung, die solche Variablen betrifft, die global deklariert sind und Verweise auf Ribbon-Definitionen speichern.<\/p>\n
Warum machen wir das überhaupt Nun: Der Verweis auf eine Ribbon-Definition wird nur einmal beim Anwenden der Ribbon-Definition geliefert, und zwar mit der Prozedur, die Sie für das Ereignisattribut onLoad <\/b>hinterlegen können. Diese enthält einen Parameter namens ribbon <\/b>mit dem Datentyp IRibbonUI<\/b>.<\/p>\n
Damit wir später auf diese Variable zugreifen können, müssen wir diese als globale Variable speichern. Dazu verwenden wir die folgende Variable, die wir in einem Standardmodul beispielsweise namens mdlRibbons <\/b>deklarieren:<\/p>\n
Public <\/span>objRibbon_Main As <\/span>IRibbonUI<\/pre>\n
In der Ribbon-Definition legen wir für das Element CustomUI <\/b>ein Attribut namens onLoad <\/b>an, das den Namen der Prozedur enthält, die beim Laden der Ribbondefinition ausgeführt werden soll – außerdem hinterlegen wir für das button<\/b>-Element btn <\/b>noch ein Callbackattribut namens getEnabled<\/b>, mit dem wir gleich prüfen können, ob die Invalidate<\/b>-Methode des Ribbons funktioniert:<\/p>\n
<xml version=\"1.0\">\r\n<customUI ... onLoad=\"OnLoad_Main\">\r\n   <ribbon>\r\n     <tabs>\r\n       <tab id=\"tab\" label=\"Beispieltab\">\r\n         <group id=\"grp\" label=\"Beispielgruppe\">\r\n           <button id=\"btn\" getEnabled=\"getEnabled\"             label=\"Beispielbutton\"\/>\r\n         <\/group>\r\n       <\/tab>\r\n     <\/tabs>\r\n   <\/ribbon>\r\n<\/customUI><\/pre>\n
Die Prozedur für das Attribut onLoad<\/b> enthält lediglich eine Anweisung, die den mit dem Parameter ribbon <\/b>übergebenen Verweis in der Variablen objRibbon_Main <\/b>speichert:<\/p>\n
Sub <\/span>onLoad_Main(ribbon As <\/span>IRibbonUI)\r\n     Set<\/span> objRibbon_Main = ribbon\r\nEnd Sub<\/span><\/pre>\n
Außerdem hinterlegen wir im Modul mdlRibbons <\/b>noch eine Variable für den Enabled<\/b>-Zustand der Schaltfläche btn<\/b>:<\/p>\n
Public <\/span>bolEnabled As Boolean<\/span><\/pre>\n
Für das Attribut getEnabled <\/b>des button<\/b>-Elements btn <\/b>hinterlegen wir die folgende Prozedur, welche mit dem Parameter enabled <\/b>den Wert der Variablen bolEnabled <\/b>zurückgibt:<\/p>\n
Sub <\/span>getEnabled(control As <\/span>IRibbonControl, ByRef enabled)\r\n     enabled = bolEnabled\r\nEnd Sub<\/span><\/pre>\n
Testen, ob die Ribbon-Variable bei Fehler geleert wird<\/h2>\n
<\/p>\n
Wenn Sie die Ribbon-Definition wie hier beschrieben und in der Beispielanwendung umgesetzt angelegt haben, sollte nach einem Neustart der Anwendung das Tab mit der Beschriftung Beispieltab <\/b>mit einer Gruppe Beispielgruppe <\/b>und einer Schaltfläche Beispielbutton <\/b>erscheinen (siehe Bild 3).<\/p>\n
\"Das<\/p>\n
Bild 3: Das Beispielribbon in Aktion<\/span><\/b><\/p>\n
Die Schaltfläche ist nicht aktiviert, da die Variable bol-Enabled <\/b>standardmäßig den Wert False <\/b>hat und noch nicht auf True <\/b>eingestellt wurde.<\/p>\n
Also liefert die Prozedur getEnabled <\/b>den Wert False <\/b>für den Parameter enabled<\/b>, der dann an das aufrufende button<\/b>-Element weitergegeben wird.<\/p>\n
Nun probieren wir, ob auch das Zuweisen des IRibbon-UI<\/b>-Objekts funktioniert hat. Dazu rufen wir die folgende Prozedur auf. Diese stellt zunächst bolEnabled <\/b>auf True <\/b>ein. Beim nächsten Aufruf von getEnabled <\/b>sollte also die Schaltfläche btn <\/b>aktiviert werden. Außerdem ruft die Prozedur die Invalidate<\/b>-Methode von objRibbon_Main <\/b>auf:<\/p>\n
Public Sub <\/span>BeispielbuttonAktivieren()\r\n     bolEnabled = True<\/span>\r\n     objRibbon_Main.Invalidate\r\nEnd Sub<\/span><\/pre>\n
Dies führt dazu, dass die Schaltfläche btn<\/b> nun aktiviert dargestellt wird (siehe Bild 4). Mit der folgenden Prozedur können Sie diese wieder deaktivieren:<\/p>\n
\"Die<\/p>\n
Bild 4: Die nun aktivierte Schaltfläche im Ribbon<\/span><\/b><\/p>\n
Public Sub <\/span>BeispielbuttonDeaktivieren()\r\n     bolEnabled = False<\/span>\r\n     objRibbon_Main.Invalidate\r\nEnd Sub<\/span><\/pre>\n
Damit können wir nun wieder einen unbehandelten Fehler auslösen:<\/p>\n
Public Sub <\/span>RaiseError()\r\n     Debug.Print<\/span> 1 \/ 0\r\nEnd Sub<\/span><\/pre>\n
Versuchen wir nun, mit der Prozedur BeispielbuttonAktivieren <\/b>die Schaltfläche im Ribbon wieder zu aktivieren, erhalten wir den Fehler aus Bild 5. Genau dieses Verhalten wollen wir nun ändern.<\/p>\n
\"Fehler<\/p>\n
Bild 5: Fehler beim Versuch, das Ribbon zu invalidieren<\/span><\/b><\/p>\n
Was speichert eine Objektvariable<\/h2>\n
Um die folgenden Schritte besser nachvollziehen zu können, müssen Sie wissen, was eine Objektvariable eigentlich speichert – was auch der Grund ist, warum wir meist schreiben, dass eine Objektvariable ein Objekt referenziert und eben nicht das Objekt selbst enthält.<\/p>\n
Tatsächlich enthält die Objektvariable nämlich nur die Speicheradresse, an der sich das jeweilige Objekt befindet. Und genau diese ist der Punkt, an dem unsere nachfolgend beschriebene Lösung ansetzt.<\/p>\n
Die Rolle der TempVars<\/h2>\n
Mit Access 2010 wurden die TempVars <\/b>eingeführt. TempVars <\/b>sind eine Auflistung, in der Sie beliebige Name-Wert-Paare speichern können. Dabei nutzen wir die Add<\/b>-Methode dieser Auflistung, um Elemente hinzuzufügen:<\/p>\n
TempVars.Add \"Name\", \"Wert\"<\/pre>\n
Um einen Wert wieder auszulesen, verwenden Sie einfach den Namen des Wertes als Parameter:<\/p>\n
Debug.Print<\/span> TempVars(\"Name\")<\/pre>\n
Was ist der Clou Warum nicht einfach eine globale Variable verwenden Der große Vorteil der TempVars<\/b>-Auflistung ist, dass die darin enthaltenen Daten nicht beim Auftreten eines unbehandelten Laufzeitfehlers geleert werden – auch nicht, wenn Sie einen Zeiger auf eine Objektvariable als Wert übergeben.<\/p>\n
Speichern des Zeigers auf die Ribbondefinition per TempVar<\/h2>\n
Es hilft uns nun nicht weiter, wenn wir einfach die Objektvariable in der TempVars<\/b>-Auflistung speichern und diese bei Bedarf wieder hervorholen, um deren Invalidate<\/b>– oder InvalidateControl<\/b>-Methode aufzurufen.<\/p>\n
Stattdessen speichern wir die Speicheradresse des mit dieser Objektvariablen verknüpften Objekts in der TempVars<\/b>-Auflistung. Die Speicheradresse eines Objekts liefert uns wiederum die Funktion ObjPtr<\/b>, der Sie die Objektvariable als Parameter übergeben:<\/p>\n
Sub <\/span>onLoad_Main(ribbon As <\/span>IRibbonUI)\r\n     Set<\/span> objRibbon_Main = ribbon\r\n     TempVars.Add \"objRibbon_Main\", ObjPtr(ribbon)\r\nEnd Sub<\/span><\/pre>\n
Ob die Funktion ObjPtr <\/b>tatsächlich eine Speicheradresse liefert, können Sie auch am Beispiel der oben definierten Variablen db <\/b>prüfen:<\/p>\n
Debug.Print<\/span> ObjPtr(db)<\/pre>\n
Wenn db <\/b>leer ist, liefert dies den Wert 0<\/b>, anderenfalls eine Speicheradresse wie 618085052<\/b>.<\/p>\n
Objektvariable wiederherstellen<\/h2>\n
Nun haben wir allerdings ein Problem: Wir können zwar mit der Funktion ObjPtr <\/b>die Speicheradresse eines Objekts ermitteln, aber wie können wir das Objekt wiederherstellen, wenn es zwischenzeitlich geleert wurde<\/p>\n
Dazu nutzen wir die Prozedur aus Listing 1, die speziell für das Wiederherstellen von Objekten des Typs IRibbonUI <\/b>aus TempVars<\/b>-Auflistungen heraus programmiert wurde.<\/p>\n
Private <\/span>Declare Sub CopyMemory Lib \"kernel32.dll\" Alias \"RtlMoveMemory\" (ByRef Destination As <\/span>Any, _\r\n     ByRef Source As <\/span>Any, ByVal Length As Long<\/span>)\r\n     \r\nPublic Sub <\/span>RebuildIRibbonUI(objRibbon As <\/span>IRibbonUI, strRibbon As String<\/span>)\r\n     Dim <\/span>lngObject As Long<\/span>\r\n     Dim <\/span>obj As Object<\/span>\r\n     lngObject = TempVars(strRibbon)\r\n     If <\/span>lngObject <> 0 Then<\/span>\r\n         CopyMemory obj, lngObject, 4&\r\n         Set<\/span> objRibbon = obj\r\n         CopyMemory obj, 0&, 4&\r\n     End If<\/span>\r\nEnd Sub<\/span><\/pre>\n
Listing 1: Prozedur zum Wiederherstellen einer IRibbonUI-Objektvariablen auf Basis ihrer Speicheradresse<\/span><\/b><\/p>\n
Hier sehen wir zunächst die Deklaration einer API-Funktion namens CopyMemory<\/b>. Diese dient dem Kopieren von Speicherbereichen.<\/p>\n
Die Prozedur RebuildIRibbonUI <\/b>erwartet zwei Parameter:<\/p>\n