Januar 20, 2021, 14:28:55

Neuigkeiten:

Ist euer Problem gelöst, dann bitte den Knopf "Thema gelöst" drücken!


Access Umstieg von 32-bit auf 64 -bit Version - Problem mit Programm

Begonnen von nkh2016, März 30, 2017, 14:00:30

⏪ vorheriges - nächstes ⏩

nkh2016

Hallo...

Beiliegendes Programm (Demo - Bilder über Webcam einfügen) funktionierte problemlos in der 32-bit Version - bin nun auf 64-bit Version umgestiegen.

Nun funktioniert das Programm (Kamera Bildaufnahme Demo) nicht mehr....

Es kommt folgende Fehlermeldung... siehe Bild 1... und Bild 2

Habe die Declare (32-bit) auf  Declare PtrSafe (64-bit), sowie Long auf LongPtr geändert...
Diesen Hinweis habe ich im Internet gefunden, muss aber nicht stimmen...

Nun happert´s in der Sub Form_open..... (siehe Bild 2)...

Meine vba-Kenntnisse reichen dafür leider nicht aus...

Danke für eure Bemühungen....

lg kh





nkh2016

Hat sich erledigt.... werde bei der 32-bit Version bleiben... habe mich auch in anderen Foren umgeschaut...

Danke trotzdem... lg kh

MaggieMay

Hi,

ich hatte letztes Jahr ebenfalls den Versuch unternommen, auf Office 64-Bit umzustellen und habe es nach einigen Wochen intensiven Bemühens wieder aufgegeben. Es ist nicht so einfach, wie es auf den ersten Blick aussieht. Sämtliche Long-Deklarationen auf LongPtr umzustellen, ist ganz gewiss nicht die Lösung, und im Einzelfall auch gar nicht angebracht. Insgesamt ist das Thema von Microsoft stiefmütterlich behandelt worden und ausgesprochen schlecht (bzw. gar fehlerhaft) dokumentiert.

Berichte von erfolgreichen Umstellungen wären an dieser Stelle sicherlich interessant und äußerst willkommen.
Freundliche Grüße
MaggieMay

PhilS

Zitat von: MaggieMay am April 02, 2017, 02:09:05ich hatte letztes Jahr ebenfalls den Versuch unternommen, auf Office 64-Bit umzustellen und habe es nach einigen Wochen intensiven Bemühens wieder aufgegeben.
[...]
Insgesamt ist das Thema von Microsoft stiefmütterlich behandelt worden und ausgesprochen schlecht (bzw. gar fehlerhaft) dokumentiert.


Ich finde die Erläuterungen im 64-Bit Visual Basic for Applications Overview sehr hilfreich und eigentlich auch umfassend. Der einzige Kritikpunkt, den ich daran hätte, ist, dass dieser Text meines Wissens nur in Englisch verfügbar ist.

Ein grundsätzliches Problem bei der Umstellung ist, dass es viele API-Beispiele gibt, die vor langer Zeit mal geschrieben wurden und daher nicht auf 64-Bit ausgelegt sind. Wer nun diese Beispiele, ohne sie zu verstehen, in die eigene Anwendung kopiert hat, der ist natürlich mit der Umstellung derselben herausgefordert.

Und an diesem Punkt bin ich etwas gespalten. Einerseits ist es natürlich nur eingeschränkt empfehlenswert, Code zu kopieren, den man nicht versteht. Auf der anderen Seite biete auch ich auf meiner Webseite Code an, der komplexere Funktionalität in einer einfach verwendbaren Form kapselt. Dies auch mit der Intention, dass ihn Anfänger einfach kopieren und verwenden können, ohne ihn komplett zu verstehen. Auch meine eigenen Beispiele sind nicht alle 64-Bit-kompatibel programmiert.  :-/

Nun, was tun?
Niemand der kostenlos Codebeispiele bereitstellt, kann verpflichtet werden, diese über Jahre in die Zukunft zu warten und zu aktualisieren.

Ich würde durchaus auch einen längeren Hilfe-Text zur Migration auf x64 verfassen, aber ich sehe noch nicht den Ansatzpunkt. Eine Migration müsste m.E. auf einer Case-By-Case-Basis erfolgen. Eine allgemeine Richtlinie, die über den o.g. MSDN-Artikel hinausgeht, ist schwierig zu formulieren, weil die Umstellung von jeder API-Funktionssignatur zumindest im Groben auch deren Verständnis erfordert.

@MaggieMay: Kannst du konkretisieren ...

  • woran du gescheitert bist,

  • in welcher Hinsicht die bestehende Dokumentation unklar oder fehlerhaft ist,

  • und wozu und in welcher Form du dir weitergehende Hilfestellung wünscht?


Zitat von: MaggieMay am April 02, 2017, 02:09:05Berichte von erfolgreichen Umstellungen wären an dieser Stelle sicherlich interessant und äußerst willkommen.

Ich hatte selbst noch nicht die Anforderung eine komplette VBA-Anwendung umzustellen. Bei der Umstellung bzw. dem Test von isolierten VBA-Codebeispielen sowie der Umstellung/Erweiterung einer VB.net-Anwendung, die intensiven Gebrauch von Win-API-Deklarationen macht und in diesem Punkt daher ähnlich zu behandeln ist, auf 64-Bit habe ich jedoch bisher keine nennenswerten Probleme gehabt.
Access DevTools - Find and Replace
Komfortables Suchen und Ersetzen in den Entwurfseigenschaften von Access-Objekten. In Abfragen, Formularen, Berichten und VBA-Code - Überall und rasend schnell!

MaggieMay

Hallo Phil,

ich kann jetzt leider keine konkreten Details mehr liefern, da das Projekt der Umstellung auf Office 64 Bit zwar von mir initiiert und anfänglich betreut, aber dann von einem Kollegen übernommen und nach einigen Wochen, nach nicht erfolgreichem Abschlusstest, schließlich eingestampft wurde. Das uns damals zur Verfügung stehende Zeitfenster war einfach zu knapp bemessen.

Es handelte sich dabei um Programme, die ursprünglich vor etlichen Jahren mit Access 97 entwickelt wurden und dementsprechend viele API-Funktionen enthielten - für Funktionalitäten, die man heute teilweise anders und/oder einfacher lösen kann. Der Ansatz, eine möglichst zeitsparende 1:1-Umstellung ohne größere Änderungen, Anpassungen und Optimierungen des Codes vorzunehmen, war möglicherweise unrealistisch und kontraproduktiv.

Ich persönlich benötige hier also keine Hilfestellung mehr. Allerdings interessiere ich mich durchaus weiterhin für diese Thematik und ich wundere mich, dass es anscheinend wenig andere Betroffene mit ähnlichen Fragestellungen gibt, geschweige denn Berichte von erfolgreichen Umstellungen.
Freundliche Grüße
MaggieMay

trebuh

Hallo,

ich greife dieses Thema mal wieder heraus, da es mich nun auch betrifft, weil ich jetzt auf Office 365 umgestellt habe.
Da mir der Händler jetzt die 64-bit Variante aufgespielt hat, treten nun die Fehler in den API-Deklarationen auf.

Wieder auf die 32-bit Variante zurückgreifen habe ich eigentlich nicht mehr vor.
 
Nun habe ich die Declare-Anweisungen entsprechend korrigiert (PtfSafe, LongPtr).
Beim Debuggen taucht dann an anderer Stelle im Code der Fehler: "Fehler beim Komplimieren: Typen unverträglich"

Müssen da noch Variablen mit dem Typ Long entsprechend auf LongPtr umdeklariert werden?
Oder was muss man sonst noch korrigieren?

Gruß
Hubert
 

steffen0815

Hallo,
Zitatan anderer Stelle im Code
Ich denke die Stelle solltest du uns zeigen.
Gruß Steffen

trebuh

Hallo,

Bei diesem Code:
Option Compare Database
Option Explicit

Private Type BrowseInfo
     hwndOwner As Long
     pIDLRoot As Long
     pszDisplayName As Long
     lpszTitle As Long
     ulFlags As Long
     lpfnCallback As Long
     lParam As Long
     iImage As Long
End Type

Private Declare PtrSafe Sub CoTaskMemFree Lib "ole32.dll" (ByVal hMem As Long)

Private Declare PtrSafe Function lstrcat Lib "kernel32" Alias "lstrcatA" _
       (ByVal lpString1 As String, ByVal lpString2 As String) As LongPtr
       
Private Declare PtrSafe Function SHBrowseForFolder Lib "shell32" (lpbi As BrowseInfo) As LongPtr

Private Declare PtrSafe Function SHGetPathFromIDList Lib "shell32" (ByVal pidList As Long, _
       ByVal lpBuffer As String) As LongPtr
       
Private Const BIF_RETURNONLYFSDIRS = 1
Private Const MAX_PATH = 256

Public Function BrowseForFolder(Beschriftung As String) As String
Dim pidl As Long
Dim path As String
Dim bi As BrowseInfo

  bi.hwndOwner = Screen.ActiveForm.hwnd
  bi.lpszTitle = lstrcat(Beschriftung, "")   '<<<<------Hier meckert der Debugger
  bi.ulFlags = BIF_RETURNONLYFSDIRS
  pidl = SHBrowseForFolder(bi)
  If pidl Then
     path = String(MAX_PATH, 0):     SHGetPathFromIDList pidl, path
     CoTaskMemFree pidl
     path = Left$(path, InStr(path, vbNullChar) - 1)
  End If
  BrowseForFolder = path
End Function

Markiert der Debugger diese Zeile:
bi.lpszTitle = lstrcat(Beschriftung, "")


steffen0815

Hallo,
UNGETESTET     Public Declare PtrSafe Function lstrcat Lib "kernel32" Alias "lstrcatA" _
            (ByVal lpString1 As String, ByVal lpString2 As String) As Long


Prinzipiell sollte der Code nmM durch die entsprechenden Office-Dialoge ersetzt werden.
Gruß Steffen

trebuh

Hallo Steffen,

vielen Dank.
Scheinbar war es ein Fehler pauschal in allen Declare-Anweisungen das Long in LonPtr zu ersetzen.

PhilS

Zitat von: trebuh am Dezember 03, 2020, 08:44:33Scheinbar war es ein Fehler pauschal in allen Declare-Anweisungen das Long in LonPtr zu ersetzen.
Du hast ja nur die Rückgabewerte geändert. Außerdem musst du auch die Argumente und die Elemente in dem Benutzerdefinierten Type BrowseInfo prüfen und ggfls. anpassen. Generell ist eine pauschale Änderungen von jedem Long in LongPtr ist nicht korrekt.

Zitat von: steffen0815 am Dezember 03, 2020, 07:41:20UNGETESTET
    Public Declare PtrSafe Function lstrcat Lib "kernel32" Alias "lstrcatA" _
            (ByVal lpString1 As String, ByVal lpString2 As String) As Long
Die Deklaration von Steffen ist falsch. Der Rückgabewert von lstrCat ist tatsächlich ein LongPtr.

Zufällig bin ich heute dazu gekommen meinen Text zu Windows API-Deklarationen in VBA für 64-bit endlich auf Deutsch zu übersetzen. Darin ist das ganze Thema ausführlich erklärt.
Access DevTools - Find and Replace
Komfortables Suchen und Ersetzen in den Entwurfseigenschaften von Access-Objekten. In Abfragen, Formularen, Berichten und VBA-Code - Überall und rasend schnell!