FINAL EDIT: Es scheint tatsächlich ein Compiler Bug zu sein - siehe die angenommene Antwort.
Unter Verwendung von VBA in Excel 2007 habe ich den folgenden Code in 'Class1':
%Vor%und einige Moduscodes in einem Modul:
%Vor%Wenn 'extern' aus dem direkten Fenster wie folgt aufgerufen wird:
%Vor%Ich bekomme eine Ausgabe zurück, die seltsam erscheint:
%Vor%Es scheint wichtig zu sein, ob die aufgerufene Routine in einem Klassenmodul ist oder nicht, ob es ein Sub oder eine Funktion ist und ob ein Anfangsargument vorhanden ist oder nicht. Fehle ich etwas darüber, wie VBA funktionieren soll? Irgendwelche Ideen?
Die seltsame Zahl ändert sich von Lauf zu Lauf. Ich sage "sieht verdächtig wie ein Zeiger aus", denn wenn ich das anrufe:
%Vor%wie folgt:
%Vor%Ich bekomme die Ausgabe wie folgt zurück:
%Vor%Es ist die Erhöhung um 16, die mich misstrauisch macht, aber ich weiß es wirklich nicht. Übergeben Sie auch einen Wert, sagen Sie:
%Vor%funktioniert gut.
BEARBEITEN: Ein wenig mehr Info ... Wenn ich den Rückgabewert von 'c.strange' etwas zuweisen, anstatt es wegzuwerfen, bekomme ich das gleiche Verhalten:
%Vor%Interessanterweise ändert sich der angenommene Zeigerwert, wenn ich meine Testroutinen wie oben beschrieben mit einem Argument aufrufen, das sich aus dem Aufruf von 'Array' ergibt. Aber wenn ich es so nenne:
%Vor%Ich bekomme die gleiche Nummer zurück, auch wenn ich den Anruf wiederholt mache. (Die Nummer ändert sich, wenn ich in Windows zu einer anderen App wechsle, wie in meinem Browser.) Nun, ich bin fasziniert, dass der Excel-Evaluator (der mit den Klammern aufgerufen wird) scheinbar seine Ergebnisse zwischenspeichert ...
Jetzt ist das großartig.
Reproduziert im Büro 2003.
Sieht wie ein Compilerfehler aus.
Das Problem ist in dieser Zeile:
%Vor% Hier erstellt der Compiler ein Variant , das ein 1D-Array von Variant s enthält, dessen einziges Element ein Zeiger anstelle des Werts ist. Dieser Zeiger geht dann zur Funktion strange , die eigentlich nicht seltsam ist, sondern nur den Wert Variant\Long , der an sie übergeben wird.
Dieser Trick bringt die Compilerfähigkeit zurück:
%Vor%BEARBEITEN
Ja, diese magische Zahl ist ein Zeiger auf die VARIANT-Struktur, die an die Methode strange übergeben werden soll. Das erste Feld ist 8 , das ist vbString , und das Datenfeld enthält einen Zeiger auf die tatsächliche Zeichenfolge "a" .
Daher ist es definitiv ein Compiler-Bug ... Noch ein VB-Compiler-Fehler in Bezug auf Arrays;)
Tags und Links vba excel compiler-bug