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.
Als ich von einem Entwicklerkollegen hörte, dass es nunmehr endlich eine 64bit-Version der MSCOMCTL.ocx 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.
Experimente
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).
Bild 1: Einfügen des TreeView-Steuerelements unter 64bit
Das so hinzugefügte Steuer-element hat den Namen ctlTreeView bekommen. Um es zu testen, habe ich folgenden Code zum Klassenmodul des Formulars hinzugefügt:
Private Sub Form_Load() Dim objTreeView As MSComctlLib.TreeView Set objTreeView = Me!ctlTreeView.Object objTreeView.Nodes.Add , , , "Test" End Sub
Das Ergebnis sehen Sie in Bild 2: Das TreeView wird angezeigt und funktioniert wie gewünscht.
Bild 2: Das TreeView-Steuerelement funktioniert!
TreeView: Von 32bit zu 64bit und zurück
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.
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.
Anwendung umrüsten
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.
Probleme im Code
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).
Bild 3: Fehlerhaft markierte API-Funktionen
Der Menübefehl Debuggen|Kompilieren 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 erweitern. Nur wo Das ist nach kurzem Experimentieren beantwortet – nämlich zwischen Declare und Function/Sub:
Bild 4: Meldung beim Versuch, das Projekt zu debuggen
Private Declare PtrSafe Function SendMessage Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, _ ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
Dies manuell zu erledigen ist natürlich eine langweilige Aufgabe. Also ziehen wir den Suchen/Ersetzen-Dialog zur Unterstützung heran und geben im Suchen nach-Textfeld den Ausdruck Declare Function und im Ersetzen durch-Textfeld den Ausdruck Declare PtrSafe Function (siehe Bild 5).
Bild 5: Suchen und Ersetzen
Der folgende Versuch, die Anwendung zu debuggen, liefert die Declare Sub-Deklarationen als fehlerhafte Zeilen. Also führen wir den Suchen/Ersetzen-Vorgang nochmals durch, nur diesmal mit dem Suchbegriff Declare Sub und dem Ersetzungsausdruck Declare PrtSafe Sub.
Danach versuchen wir erneut, die Anwendung zu kompilieren. Nun tauchen Fehler wie der in Bild 6 auf. Was ist hier das Problem
Bild 6: Unverträgliche Typen
Um dies herauszufinden, schauen wir uns über den Kontextmenü-Eintrag Definition die Definition des markierten Elements an, hier der Funktion VarPtr (Bild 7). Diese erwartet als Parameter einen Wert des Typs Any und liefert einen Wert des Typs LongPtr zurück.
Sie haben das Ende des frei verfügbaren Textes erreicht. Möchten Sie ...
Oder bist Du bereits Abonnent? Dann logge Dich gleich hier ein. Die Zugangsdaten findest Du entweder in der aktuellen Print-Ausgabe auf Seite U2 oder beim Online-Abo in der E-Mail, die Du als Abonnent regelmäßig erhältst:
