<\/p>\n
Es ist geschehen: Jahre nach der Einführung der ersten 64bit-Version von Microsoft Access (wer erinnert sich noch) hat Microsoft die 64bit-Version auch mit einer passenden Version der Bibliothek MSCOMCTL.ocx versehen. Das Fehlen von TreeView, ListView und Co. war bisher einer der Hauptgründe, nicht auf 64bit zu wechseln. Derweil gehen dennoch viele Unternehmen diesen Schritt – meist vermutlich einfach, um eine „modernere“ Version von Access zu nutzen. Hier und da vernimmt man allerdings auch Stimmen, dass die 64bit-Version an verschiedenen Stellen Probleme vermeidet, die unter der 32bit-Version aufgetreten sind. In diesem Beitrag schauen wir uns an, was beim Einsatz von Steuerelementen der MSCOMCTL.ocx-Bibliothek zu beachten ist und wie Sie 32bit-Anwendungen fit machen für die 64bit-Version.<\/b><\/p>\n
Als ich von einem Entwicklerkollegen hörte, dass es nunmehr endlich eine 64bit-Version der MSCOMCTL.ocx <\/b>gibt, habe ich alles andere liegen lassen und eine virtuelle Maschine mit Office 2016 in der 64bit-Version ausgestattet. Anmerkung an dieser Stelle: Dies geschah mit einer Office-Version eines Office 365-Abonnements.<\/p>\nExperimente<\/h2>\n
Unter der 64bit-Version von Access habe ich also eine neue Datenbank erstellt, dieser ein Formular hinzugefügt und dann tatsächlich in der Liste der verfügbaren ActiveX-Steuerelemente das TreeView-Steuerelement gefunden (siehe Bild 1).<\/p>\n
![\"Einfügen](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_001.png\")
<\/p>\n
Bild 1: Einfügen des TreeView-Steuerelements unter 64bit<\/span><\/b><\/p>\n Das so hinzugefügte Steuer-element hat den Namen ctlTreeView <\/b>bekommen. Um es zu testen, habe ich folgenden Code zum Klassenmodul des Formulars hinzugefügt:<\/p>\n Das Ergebnis sehen Sie in Bild 2: Das TreeView wird angezeigt und funktioniert wie gewünscht.<\/p>\n Bild 2: Das TreeView-Steuerelement funktioniert!<\/span><\/b><\/p>\n Wir haben dann die unter der 64bit-Version von Access erstellte Datenbank auf ein System mit Access in der 32bit-Version von Access kopiert und gestartet. Das TreeView-Steuerelement dieser mit der 64bit-Version erstellten Datei funktioniert auch unter der 32bit-Version.<\/p>\n Danach haben wir die gleiche Datei unter Access in der 32bit-Version erstellt und diese dann auf das mit der 64bit-Version ausgestattete System kopiert. Auch hier gelingt die Anzeige des TreeView-Steuerelements ohne Probleme.<\/p>\n Damit sind die Voraussetzungen gegeben, einen genaueren Blick auf die Umrüstung einer Anwendung auf Basis von 32bit-Access auf die 64bit-Version zu werfen – oder gleich auf eine Umrüstung, die mit beiden Versionen kompatibel ist. Dazu nehmen wir uns als Beispiel die Ribbon-Admin-Anwendung vor, die eine Menge API-Code enthält – und genau dieser ist in der Regel nicht kompatibel mit 64bit-Systemen, wenn er unter 32bit-Access geschrieben wurde.<\/p>\n Die offensichtlichen Probleme tauchen schon auf, wenn Sie die Moduls mit API-Deklarationen einer 32bit-Datenbank öffnen – die API-Funktionen werden komplett rot markiert, was kein gutes Zeichen ist (siehe Bild 3).<\/p>\n Bild 3: Fehlerhaft markierte API-Funktionen<\/span><\/b><\/p>\n Der Menübefehl Debuggen|Kompilieren <\/b>liefert dann genauere Informationen in Form einer Meldung (siehe Bild 4). Die Erläuterung ist eindeutig – wir sollen die Deklarationen mit dem Schlüsselwort PtrSafe <\/b>erweitern. Nur wo Das ist nach kurzem Experimentieren beantwortet – nämlich zwischen Declare <\/b>und Function<\/b>\/Sub<\/b>:<\/p>\n Bild 4: Meldung beim Versuch, das Projekt zu debuggen<\/span><\/b><\/p>\n Dies manuell zu erledigen ist natürlich eine langweilige Aufgabe. Also ziehen wir den Suchen\/Ersetzen<\/b>-Dialog zur Unterstützung heran und geben im Suchen nach<\/b>-Textfeld den Ausdruck Declare Function <\/b>und im Ersetzen durch<\/b>-Textfeld den Ausdruck Declare PtrSafe Function <\/b>(siehe Bild 5).<\/p>\n Bild 5: Suchen und Ersetzen <\/span><\/b><\/p>\n Der folgende Versuch, die Anwendung zu debuggen, liefert die Declare Sub<\/b>-Deklarationen als fehlerhafte Zeilen. Also führen wir den Suchen\/Ersetzen-Vorgang nochmals durch, nur diesmal mit dem Suchbegriff Declare Sub <\/b>und dem Ersetzungsausdruck Declare PrtSafe Sub<\/b>.<\/p>\n Danach versuchen wir erneut, die Anwendung zu kompilieren. Nun tauchen Fehler wie der in Bild 6 auf. Was ist hier das Problem<\/p>\n Bild 6: Unverträgliche Typen<\/span><\/b><\/p>\n Um dies herauszufinden, schauen wir uns über den Kontextmenü-Eintrag Definition<\/b> die Definition des markierten Elements an, hier der Funktion VarPtr<\/b> (Bild 7). Diese erwartet als Parameter einen Wert des Typs Any <\/b>und liefert einen Wert des Typs LongPtr <\/b>zurück.<\/p>\n <\/p>\n Bild 7: Prüfen der Datentypen von Parameter und Rückgabewert<\/span><\/b><\/p>\n Der Datentyp LongPtr<\/b> ist 64bit-kompatibel und umfasst einen Wertebereich von 2 hoch 64, während der 32bit-kompatible Datentyp Long <\/b>nur 2 hoch 32 Werte umfasst.<\/p>\n Warum aber macht die Funktion VarPtr <\/b>nun Probleme Dazu schauen wir uns die Deklaration der API-Funktion StringFromGUID2 <\/b>an, der wir das Ergebnis dieser Funktion als Parameter übergeben. Diese sieht wie folgt aus:<\/p>\n Wir sehen, dass der zweite Parameter dieser Funktion in der Deklaration den Datentyp Long <\/b>hat. Im Aufruf der Funktion übergeben wir aber den Datentyp LongPtr<\/b>. Warum ist das nun ein Fehler, obwohl es ja zuvor unter der 32bit-Version von Access funktioniert hat Hier sind LongPtr<\/b>-Variablen mit Long<\/b>-Variablen kompatibel. Unter der 64bit-Version ist das allerdings nicht der Fall – hier könnten ja die LongPtr<\/b>-Variablen mit Werten gefüllt sein, die nicht mehr in den Wertebereich einer Long<\/b>-Variablen passen.<\/p>\n Also müssen wir überall, wo eine LongPtr<\/b>-Variable vorkommt, die in einer API-Deklaration als Parameter verwendet wird, in der API-Deklaration auch von Long <\/b>auf LongPtr <\/b>umstellen. Also ändern wir hier den Datentyp des Parameters lpstrClsId <\/b>von Long <\/b>zu LongPtr<\/b>:<\/p>\n Auf diese Weise schreiten wir weiter voran und ersetzen die Parameter des Datentyps Long <\/b>durch den Datentyp LongPtr<\/b>, wo es beim Kompilieren zu Problemen kommt.<\/p>\n Das kann beispielsweise auch einmal in einer Variablen auf Basis eines Type<\/b>-Elements geschehen (siehe Bild 8). Die Ursache des Problems liegt in den folgenden beiden Type<\/b>-Deklarationen:<\/p>\n Bild 8: Noch mehr unverträgliche Typen, diesmal in einem Type<\/span><\/b><\/p>\n Hier müssen wir zumindest einmal den Datentyp des Elements Value <\/b>von Long <\/b>auf LongPtr <\/b>ändern.<\/p>\n Interessanterweise kommen wir nach wenigen änderungen schon an dem Punkt an, wo das Kompilieren ohne Probleme gelingt.<\/p>\n Also starten wir die Anwendung, die gleich zu Beginn beispielsweise einige der GDI-API-Funktionen nutzt, um die Bilder für Kontextmenüs und TreeView bereitzustellen. Leider stürzt Access dabei komplett ab – und das, obwohl wir doch erfolgreich kompiliert haben.<\/p>\n Also bleibt uns nichts über, als schrittweise durch die beim Starten ausgeführten Anweisungen der Anwendung zu laufen und zu schauen, welche der Anweisungen den Fehler auslöst, der zum Absturz führt.<\/p>\n Hier hat sich folgende Vorgehensweise bewährt, wenn viel Code durchlaufen wird: Sie durchlaufen immer ein paar Anweisungen und setzen dann, bevor Sie fortfahren, einen fixen Haltepunkt in Form der Anweisung Stop<\/b>. Danach das Speichern nicht vergessen, denn wenn sie nun weiterlaufen und die den Absturz auslösende Anweisung ausführen, wird eine nicht gespeicherte änderung am Code natürlich auch wieder verworfen. Am besten fügen Sie also immer eine Stop<\/b>-Anweisung ein, wenn die nächsten Anweisungen den Aufruf einer oder mehrerer API-Funktionen enthalten.<\/p>\n Wenn Sie dann auf den Fehler stoßen, können Sie beim nächsten Start gleich schon einmal einige Stop<\/b>-Anweisungen löschen, die gegebenenfalls schon ohne Fehler durchlaufen werden konnten.<\/p>\n In diesem Fall stellte sich heraus, dass der Aufruf der Funktion GdipCreateHBITMAPFromBitmap <\/b>zum Absturz führt. Also schauen wir uns an, welche Parameter diese enthält und welche Datentypen diese haben. Dann gleichen wir diese mit den Datentypen der übergebenen Variablen ab. Die Definition der API-Funktion sieht so aus:<\/p>\n Wir haben also drei Long<\/b>-Parameter und auch einen Rückgabewert vom Typ Long<\/b>. Der Aufruf lautet wie folgt:<\/p>\n lBitmap <\/b>hat den Datentyp Long<\/b>, hBmp <\/b>hat den Datentyp Long<\/b>. Wo also ist das Problem lBitmap <\/b>hat aktuell den Wert 2.064.200.912<\/b>, hBmp <\/b>den Wert 0<\/b>.<\/p>\n Stellen wir versuchsweise die Datentypen der beiden Variablen um:<\/p>\n Auch in der API-Deklaration ändern wir die Datentypen der entsprechenden Parameter:<\/p>\n Damit ist alles gut Weit gefehlt. Natürlich wird die Funktion GdipCreateHBITMAPFromBitmap <\/b>auch noch von anderen Stellen aus aufgerufen, und auch dort müssen wir die Datentypen ändern. Dummerweise werden die Variablen, deren Datentypen wir nun ändern, auch noch als Parameter für den Aufruf weiterer API-Funktionen genutzt. Also haben wir eine Menge Arbeit vor uns und hangeln uns nun durch die änderungen von Datentypen von Variablen und Parametern in den API-Deklarationen.<\/p>\n Nach ein paar änderungen von Long<\/b> in LongPtr <\/b>wird die Kompilierung dann anstandslos durchgeführt und wir können erneut einen Start der Anwendung wagen. Im Falle der API-Funktion GdipCreateHBITMAPFromBitmap<\/b> gelingt die Ausführung nun. Also lassen wir die Anwendung nun weiterlaufen und setzen hier und da Stop<\/b>-Anweisungen, um uns an den nächsten Absturz heranzutasten.<\/p>\n Schließlich gelingt es dann, die Anwendung komplett zum Laufen zu bringen. Allerdings sollte man dann auch noch einmal alle Aspekte der Anwendung testen.<\/p>\n Die interessante Frage ist nun, ob die für 64bit vorbereitete Anwendung auch noch unter 32bit läuft. Also kopieren wir diese Anwendung wieder auf ein 32bit-System und probieren es dort aus.<\/p>\n Interessanterweise funktioniert unsere Anwendung mit der Ersetzung der Datentypen Long <\/b>durch LongPtr <\/b>und die Erweiterung der API-Deklaration um das Schlüsselwort PtrSafe<\/b>. Auch das Kompilieren funktioniert ohne Probleme.<\/p>\n Dies gilt allerdings nur für die Verwendung von VBA ab Version 7. Da dies allerdings auch schon mindestens sechs Jahre alt ist, behandeln wir an dieser Stelle das Thema Kompatilität mit VBA 6 so knapp wie möglich.<\/p>\n Es gibt sogenannte Kompilierungskonstanten sowie beispielsweise If…Then…Else<\/b>-Konstrukte, die nur beim Kompilieren ausgeführt werden. Diese markieren Sie durch ein vorangestelltes Raute-Zeichen (#<\/b>). Wenn Sie eine Anweisung also kompatibel für VBA 6 und VBA 7 bereitstellen wollen, verwenden Sie etwa die folgende If…Then…Else<\/b>-Bedingung:<\/p>\n Wenn Sie also etwa eine API-Deklaration für beide VBA-Versionen bereitstellen wollen, gelingt dies etwa so:<\/p>\n Bei der Variablendeklaration erledigen Sie das auf die gleiche Weise:<\/p>\n Wenn Sie nicht auf Anhieb wissen, welche Version von Access oder VBA Sie verwenden, können Sie dies schnell testen. Um die Access-Version zu ermitteln und speziell, ob Sie die 32bit- oder 64bit-Version nutzen, betätigen Sie den Ribbon-Tab Datei|Konto <\/b>und klicken dort auf die Schaltfläche Info <\/b>zu Access. Der nun erscheinende Dialog aus Bild 9 liefert die Access-Version samt Hinweis auf die 32bit- oder 64bit-Version.<\/p>\n Bild 9: Access-Version ermitteln<\/span><\/b><\/p>\n Um die Version von VBA zu ermitteln, öffnen Sie den VBA-Editor und betätigen dort den Menü-Eintrag |Microsoft Visual Basic for Applications-Info… <\/b>(siehe Bild 10).<\/p>\n Bild 10: VBA-Version ermitteln<\/span><\/b><\/p>\n Wenn Sie eine .accde<\/b>-Version Ihrer Anwendung erstellen wollen, müssen Sie diese gegen die jeweilige Version kompilieren – also entweder 32bit oder 64bit. Sie müssen also jeweils zwei Versionen für die unterschiedlichen Access-Versionen bereithalten.<\/p>\n Das es nun eine Version der Bibliothek MSCOMCTL.ocx <\/b>für die 64bit-Version von Access gibt, ist eine gute Nachricht. Endlich müssen Entwickler ihren Auftraggeber nicht mehr erklären, warum es keine gute Idee ist, die 64bit-Version von Office zu installieren.<\/p>\n","protected":false},"excerpt":{"rendered":" Es ist geschehen: Jahre nach der Einführung der ersten 64bit-Version von Microsoft Access (wer erinnert sich noch) hat Microsoft die 64bit-Version auch mit einer passenden Version der Bibliothek MSCOMCTL.ocx versehen. Das Fehlen von TreeView, ListView und Co. war bisher einer der Hauptgründe, nicht auf 64bit zu wechseln. Derweil gehen dennoch viele Unternehmen diesen Schritt – meist vermutlich einfach, um eine „modernere“ Version von Access zu nutzen. Hier und da vernimmt man allerdings auch Stimmen, dass die 64bit-Version an verschiedenen Stellen Probleme vermeidet, die unter der 32bit-Version aufgetreten sind. In diesem Beitrag schauen wir uns an, was beim Einsatz von Steuerelementen der MSCOMCTL.ocx-Bibliothek zu beachten ist und wie Sie 32bit-Anwendungen fit machen für die 64bit-Version.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[662018,66042018,44000025],"tags":[],"class_list":["post-55001136","post","type-post","status-publish","format-standard","hentry","category-662018","category-66042018","category-VBA_und_Programmiertechniken"],"yoast_head":"\nPrivate Sub <\/span>Form_Load()\r\n Dim <\/span>objTreeView As <\/span>MSComctlLib.TreeView\r\n Set<\/span> objTreeView = Me!ctlTreeView.Object\r\n objTreeView.Nodes.Add , , , \"Test\"\r\nEnd Sub<\/span><\/pre>\n![\"Das](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_002.png\")
<\/p>\nTreeView: Von 32bit zu 64bit und zurück<\/h2>\n
Anwendung umrüsten<\/h2>\n
Probleme im Code<\/h2>\n
![\"Fehlerhaft](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_003.png\")
<\/p>\n![\"Meldung](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_004.png\")
<\/p>\nPrivate <\/span>Declare PtrSafe Function SendMessage Lib \"user32\" Alias \"SendMessageA\" (ByVal hwnd As Long<\/span>, _\r\nByVal wMsg As Long<\/span>, ByVal wParam As Long<\/span>, lParam As <\/span>Any) As Long<\/span><\/pre>\n![\"Suchen](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_005.png\")
<\/p>\n![\"Unverträgliche](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_006.png\")
<\/p>\n![\"Prüfen](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_007.png\")
<\/p>\nPrivate <\/span>Declare PtrSafe Function StringFromGUID2 Lib \"ole32.dll\" (rGUID As <\/span>Any, _\r\nByVal lpstrClsId As Long<\/span>, ByVal cbMax As Long<\/span>) As Long<\/span><\/pre>\nPrivate <\/span>Declare PtrSafe Function StringFromGUID2 Lib \"ole32.dll\" (rGUID As <\/span>Any, _\r\nByVal lpstrClsId As Long<\/span>Ptr, ByVal cbMax As Long<\/span>) As Long<\/span><\/pre>\n![\"Noch](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_008.png\")
<\/p>\nPrivate <\/span>Type EncoderParameters\r\n count As Long<\/span>\r\n Parameter As <\/span>EncoderParameter\r\nEnd Type\r\nPrivate <\/span>Type EncoderParameter\r\n UUID As <\/span>GUID\r\n NumberOfValues As Long<\/span>\r\n type As Long<\/span>\r\n Value As Long<\/span>\r\nEnd Type<\/pre>\nPrivate <\/span>Declare PtrSafe Function GdipCreateHBITMAPFromBitmap Lib \"gdiplus\" (ByVal bitmap As Long<\/span>, _\r\nhbmReturn As Long<\/span>, ByVal background As Long<\/span>) As Long<\/span><\/pre>\nGdipCreateHBITMAPFromBitmap lBitmap, hBmp, 0&<\/pre>\n
Dim <\/span>lBitmap As Long<\/span>Ptr\r\nDim <\/span>hBmp As Long<\/span>Ptr<\/pre>\nPrivate <\/span>Declare PtrSafe Function GdipCreateHBITMAPFromBitmap Lib \"gdiplus\" (ByVal bitmap As Long<\/span>Ptr, _\r\nhbmReturn As Long<\/span>Ptr, ByVal background As Long<\/span>) As Long<\/span><\/pre>\n32bit- und 64bit-kompatibel<\/h2>\n
#If VBA7 Then\r\n ''''64bit-Anweisungen\r\n#Else\r\n ''''32bit-Anweisungen\r\n#End If<\/pre>\n
#If VBA7 Then\r\n Private <\/span>Declare PtrSafe Function _\r\n CreateStreamOnHGlobal Lib \"ole32\" (ByVal hGlobal _\r\n As Long<\/span>Ptr, ByVal fDeleteOnRelease As Long<\/span>, _\r\n ByRef ppstm As <\/span>Any) As Long<\/span>\r\n#Else\r\n Private <\/span>Declare Function _\r\n CreateStreamOnHGlobal Lib \"ole32\" (ByVal hGlobal _\r\n As Long<\/span>, ByVal fDeleteOnRelease As Long<\/span>, _\r\n ByRef ppstm As <\/span>Any) As Long<\/span>\r\n#End If<\/pre>\n#If VBA7 Then\r\n Dim <\/span>lBitmap As Long<\/span>Ptr\r\n#Else\r\n Dim <\/span>lBitmap As Long<\/span>\r\n#End If<\/pre>\nVersionen identifizieren<\/h2>\n
![\"Access-Version](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_010.png\")
<\/p>\n![\"VBA-Version](\"..\/fileadmin\/_temp_\/2018_04\/pic_1136_009.png\")
<\/p>\nKompilieren<\/h2>\n
Zusammenfassung und Ausblick<\/h2>\n