TreeView 64bit ist da – Anwendungen umrüsten

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

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.

Bild 7: Prüfen der Datentypen von Parameter und Rückgabewert

Der Datentyp LongPtr ist 64bit-kompatibel und umfasst einen Wertebereich von 2 hoch 64, während der 32bit-kompatible Datentyp Long nur 2 hoch 32 Werte umfasst.

Warum aber macht die Funktion VarPtr nun Probleme Dazu schauen wir uns die Deklaration der API-Funktion StringFromGUID2 an, der wir das Ergebnis dieser Funktion als Parameter übergeben. Diese sieht wie folgt aus:

Private Declare PtrSafe Function StringFromGUID2 Lib "ole32.dll" (rGUID As Any, _
ByVal lpstrClsId As Long, ByVal cbMax As Long) As Long

Wir sehen, dass der zweite Parameter dieser Funktion in der Deklaration den Datentyp Long hat. Im Aufruf der Funktion übergeben wir aber den Datentyp LongPtr. Warum ist das nun ein Fehler, obwohl es ja zuvor unter der 32bit-Version von Access funktioniert hat Hier sind LongPtr-Variablen mit Long-Variablen kompatibel. Unter der 64bit-Version ist das allerdings nicht der Fall – hier könnten ja die LongPtr-Variablen mit Werten gefüllt sein, die nicht mehr in den Wertebereich einer Long-Variablen passen.

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo