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
Hat sich erledigt.... werde bei der 32-bit Version bleiben... habe mich auch in anderen Foren umgeschaut...
Danke trotzdem... lg kh
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.
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 (https://msdn.microsoft.com/en-us/library/office/gg264421.aspx) 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.
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.
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
Hallo,
Zitatan anderer Stelle im Code
Ich denke die Stelle solltest du uns zeigen.
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, "")
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.
Hallo Steffen,
vielen Dank.
Scheinbar war es ein Fehler pauschal in allen Declare-Anweisungen das Long in LonPtr zu ersetzen.
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 (https://codekabinett.com/rdumps.php?Lang=1&targetDoc=windows-api-deklaration-vba-64-bit) endlich auf Deutsch zu übersetzen. Darin ist das ganze Thema ausführlich erklärt.