Compiler-Konstante Win64 leer

Da kann ich also nicht testen, ob mein Code auch in ×32 funktionieren wird. Was mache ich falsch ?

Genau, mit der 64-Bit Office Version kannst Du keinen 32-Bit Code testen.

Die Anweisung #If Win64 Then tritt nur dann in Aktion wenn der Code kompiliert wird, d.h. sie ist kein normales
If XXX Then welches zur Laufzeit ausgewertet wird.

Du kannst zwar mit #If Not die 32-Bit Deklaration erzwingen, aber die wird dann mit der 64-Bit Version Probleme machen. Es geht bei diesen Sachen ja nicht darum wie der Code in VBA läuft, sondern ob der Aufruf der Funktion der externen DLL richtig funktioniert...

Bitte versuche nicht ein 2tes Office in 32-Bit zu installieren, das geht in die Hose. Ich empfehle (und verwende selber) virtuelle Maschinen für diese Zwecke (ich verwende
VirtualBox) auf denen ich ein übliches Windows mit einer üblichen Office-Version installiere um die zu erwartenden Gegebenheiten bei einem Kunden zu haben.

Andreas.

Meine Frage ist vor allem, ob das normal oder ein Bug ist oder ob irgend etwas bei mir fehlt. Win64 wird zwar als Systemvariable erkannt (z.B. wenn ich "win64" tippe wird daraus "Win64"), aber diese ist immer
leer (weder True noch False) und steuert keineswegs die #If-Bedingung beim Compilen…

Es ist kein Bug, Deine Interpretation von dem Geschehen ist einfach falsch.

Das Ding ist auch keine "Systemvariable" noch nicht mal eine Variable im eigentlichen Sinn.

Der Compiler ließt den Text und sortiert das was er nicht braucht aus. Auf einem 64-Bit System kannst Du aber sofort sehen ob die Deklaration richtig ist oder nicht:





Und wenn ich mir Dein Beispiel ankucke, dann sehe ich schon mal 2 Fehler:

a) Die 32-Bit Varainte braucht kein PtrSafe

b) LongLong bei 64-Bit ist wahrscheinlich falsch, die Dinger sind in aller Regel als LongPtr zu deklarieren.

Das ist aber nicht soo schlimm, VBA modelt das wahrscheinlich so hin das der Aufruf dann doch funktioniert...

Andreas.

Allerbesten Dank. Klar kann ich Office ×32 nicht installieren, ohne ×64 vorher zu deinstallieren. Das mache ich sicher nicht. Was ich meinte ist dass ich nicht einmal testen kann, ob die #If- Bedingung auf dem Ziel-PC das gewünschte Resultat ergeben würde,
da sie bei mir unter Office 2010 Pro ×64 überhaupt nicht funktioniert: #If Win64 und #If Not Win64 ergeben immer genau dasselbe Resultat (z.B. [k]ein Fehler je nach Variablentyp) - es wird immer nur die Zeile vor dem #Else ausgeführt. Meine Frage ist vor allem,
ob das normal oder ein Bug ist oder ob irgend etwas bei mir fehlt. Win64 wird zwar als Systemvariable erkannt (z.B. wenn ich "win64" tippe wird daraus "Win64"), aber diese ist immer
leer (weder True noch False) und steuert keineswegs die #If-Bedingung beim Compilen…

Aber ich gib's auf, die Migration auf ×32 auf dem eigenen PC vorzubereiten. Die korrekten Funktionsdeklarationen sind ja für ×32 gut bekannt (im Gegensatz zu ×64 wo verschiedene Internetquellen bezüglich der korrekten Variablentypen zum Teil widersprüchliche
Angaben machen). Ich muss einfach von jeder Vorlage mit Makros eine zweite Version für ×32 machen, das ist in dem Einzelfall noch überschaubar.

Wenn der Compiler den Code kompiliert ,damit die Maschine ihn ausführen kann, dann müssen alle Texte in Zahlen umgewandelt werden.
In diesem Fall ersetzt er xlFillValues durch eine 4. Daher nennt man das eine Konstante.
Andreas.

Anna hat ja dusseligerweise den den Code übersetzen lassen, da ist es kein Wunder, dass der Compiler das anmeckert.
Gruß
Burkhard