Excel VBA Compile wirft ein "Benutzerdefinierter Typ nicht definiert" Fehler, aber nicht auf die beleidigende Zeile des Codes gehen

Symptome

Dies ist ein Symptom, das speziell beim Kompilieren eines Excel VBA-Projekts auftritt. Der folgende Fehler tritt auf:

Benutzerdefinierter Typ nicht definiert

Der Code, der diesen Fehler verursacht, wird jedoch vom Compiler nicht hervorgehoben, so dass ich das Problem nicht identifizieren kann.

Was ich bereits weiß und versucht habe

Es handelt sich um einen "Benutzerdefinierter Typ nicht definiert" Fehler, den ich schon bei einfachen Problemen gesehen habe, z.B. wenn ich etwas As Strig statt As String benenne. Allerdings ist dieser besondere Fehler nur auftauchen, während der "Debug > Kompilieren VBAProject"-Menüoption und wenn die Fehlermeldung Feld auftaucht es nicht die Zeile des Codes, dass der Fehler auftritt, in markieren.

Nach vielen Recherchen habe ich herausgefunden, dass dieser Fehler mit fehlenden Referenzen zusammenhängen kann, und ich habe dies ausgeschlossen, da ich alle benötigten Referenzen und Toolbox-Objekte hinzugefügt habe.

Um sicherzustellen, dass ich keine offensichtlichen fehlenden "Dim"-Anweisungen übersehen habe, habe ich "Option Explicit" zu allen Codeseiten (einschließlich Formularen) hinzugefügt, um sicherzustellen, dass nichts fehlt. Der Fehler wird immer noch angezeigt, wenn ich eine Kompilierung durchführe.

Es gibt auch diesen bekannten Fehler, der besagt, dass das Problem aufgrund der VB6-Projekte, die Binärkompatibilität verwenden, bekannt ist:

Schalten Sie die Binärkompatibilität aus und kompilieren Sie das Projekt. Visual Basic hebt die Codezeile hervor, die den nicht definierten benutzerdefinierten Typ

enthält, der nicht definiert ist. Nachdem das Problem behoben wurde, kann die Binärkompatibilität wieder aktiviert werden.

Ich habe diesen Artikel über diese Frage und Antwort gefunden, allerdings kann ich diese Option im standardmäßigen Excel VBA-Editor nicht finden.

Helfen Sie mir und anderen, den Verstand zu retten!

Aus Google-Suchen und anderen Fragen weiß ich, dass ich nicht der einzige bin, der dieses Problem hat.

Ich habe versucht, den Code manuell durchzugehen, aber es gibt einfach zu viele Zeilen, um das zu schaffen.

Gibt es eine Möglichkeit, die Binärkompatibilität in Excel-VBA-Projekten zu deaktivieren? Wie finden die Leute die fehlerhafte Codezeile, wenn sie nicht herausfinden können, was sie ändern müssen? Jede Hilfe wäre schön!

Ich danke Ihnen im Voraus.

Bearbeiten: Ich habe die beanstandete Codezeile gefunden und somit ist mein spezielles Problem gelöst Das Problem ist immer noch da, nachdem ich diese spezielle Zeile entfernt habe - es war ein falsch geschriebener Name eines Steuerelements in einem Formular, auf das in seinem Code verwiesen wurde. Das löst aber immer noch nicht die Frage, wie Sie den verletzenden Code finden können, der das Problem darstellt. Sind wir in der Lage, einen guten Weg zu finden, um den fehlerhaften Code zu finden, wenn dieser Fehler auftritt, so dass andere in Zukunft diese Qualen vermeiden können?

Meine Lösung ist keine gute Nachricht, aber zumindest sollte sie funktionieren.

Mein Fall ist folgender: Ich habe eine .xlsm von einem Mitarbeiter. 1) Ich öffne die Datei und klicke auf die Schaltfläche: Es funktioniert gut. 2) Ich speichere die Datei, schließe Excel, öffne die Datei erneut: jetzt funktioniert es nicht mehr. Die Schlußfolgerung ist: der Code ist OK, aber Excel kann die Referenzen nicht richtig verwalten. (Ich habe versucht, die Verweise zu entfernen und wieder hinzuzufügen, ohne Erfolg)

Die Lösung ist also, jedes referenzierte Objekt als Variant zu deklarieren und CreateObject("Foo.Bar") anstelle von New Foo.Bar zu verwenden.

Zum Beispiel:

Dim objXML As MSXML2.DOMDocument
Set objXML = New MSXML2.DOMDocument

Ersetzt durch:

Dim objXML As Variant
Set objXML = CreateObject("MSXML2.DOMDocument")
Kommentare (1)

Da es klingt, wie Sie'haben versucht viele verschiedene mögliche Lösungen, Sie'll wahrscheinlich haben, dies zu tun die lange methodische Weise jetzt.

Erstellen Sie eine neue leere Arbeitsmappe. Kopieren Sie dann Stück für Stück Ihre alte Arbeitsmappe in diese. Fügen Sie einen Verweis hinzu, schreiben Sie ein wenig Code, um ihn zu testen. Stellen Sie sicher, dass er kompiliert und ausgeführt werden kann. Fügen Sie eine Unterfunktion oder eine Funktion hinzu, schreiben Sie wieder einen kleinen Test, um sie auszuführen, und stellen Sie ebenfalls sicher, dass sie kompiliert wird. Wiederholen Sie diesen Prozess langsam, indem Sie alles hinzufügen und testen.

Sie können diesen Vorgang etwas beschleunigen, indem Sie zunächst größere Teile ausprobieren. Wenn Sie dann einen Teil finden, der das Problem auslöst, entfernen Sie ihn und zerlegen ihn in kleinere Teile zum Testen.

Entweder finden Sie den Übeltäter, oder Sie haben eine neue Arbeitsmappe, in der das Problem auf magische Weise nicht auftritt. Letzteres wäre auf eine versteckte Beschädigung in der Arbeitsmappendatei zurückzuführen, wahrscheinlich im binären vbproject-Teil.

Willkommen in der Welt der Fehlersuche ohne Debugger oder andere hilfreiche Werkzeuge, die Ihnen die schwere Arbeit abnehmen!

Kommentare (0)

Späte Bindung

Dieser Fehler kann aufgrund einer fehlenden Referenz auftreten. Wenn zum Beispiel von früher Bindung auf späte Bindung umgestellt wird, kann durch die Eliminierung der Referenz ein Teil des Codes übrig bleiben, der auf Datentypen verweist, die für die weggefallene Referenz spezifisch sind.

Versuchen Sie, den Verweis einzufügen, um zu sehen, ob das Problem verschwindet.

Möglicherweise handelt es sich nicht um einen Compilerfehler, sondern um einen Linkerfehler, so dass die betreffende Zeile unbekannt ist. Schande über Microsoft!

Kommentare (1)