Excel, VBA, Debug, Kompilieren

Question

Hallo,

ich bin hier, weil ich Hilfe zu meinem Excel VBA Projekt brauchen könnte.

Ich habe mir über die Jahre ein kleines Excel VBA-Projekt zusammengestellt, welches stetig erweitert wird. Leider gibt es dabei immer wieder ein Problem, welches ich hier versuchen möchte, kurz zu beschreiben.

Das VBA-Projekt besteht aus verschiedenen UserFormen, die über eine zentrale Userform aufgerufen werden. Bis auf eine UserForm können alle UserFormen aufgerufen werden. Nur bei einer klappt das nicht immer! Diese eine UserForm habe ich inzwischen schon 2x neu erstellt und jedes Mal tritt das gleiche Problem wieder auf und lässt Excel "abstürzen".

Was dabei komisch ist, ist der Umstand, dass innerhalb von Excel - sprich in der Entwicklungsumgebung - dieses Problem beim Ausführen des Codes NIE auftritt, was die Suche nach dem Problem sehr schwer macht. Ich kann somit nur Vermutungen anstellen!

Auffällig ist dabei, dass das Probelm immer nur dann wirklich auftritt, wenn ich nach einer Änderung am Code in der Entwicklungsumgebung das Projekt kompiliere, speichere, Excel beende und dann den Code ausführe.

Es tritt aber nicht auf, wenn ich nach einer Änderung am Code in der Entwicklungsumgebung das Projekt nicht kompiliere sondern nur speichere, Excel beende und dann den Code ausführe. Hier kommt dann mit der Zeit jedoch ein anderer Fehler und zwar, kommt dann die Meldung, dass bei der Ausführung eine Datei nicht gefunden wird. Welche wird jedoch in der Fehlermeldung nicht angezeigt. Im Titel der Meldung steht aber "Microsoft Visual Basic for Applications". Somit kommt das wohl vom System selbst.

Jetzt meine Frage:

Gibt es beim Kopilieren Einstellungen, die man vornehmen kann bzw. optimieren kann?

Kann man das Kopilieren irgendwie überprüfen?

Schreibt Excel selber irgendwo etwas zu dem "Ausstieg" auf?

Wie kann ich ohne in der Entwicklungsumgebung von Excel zu sein, den Code beim Ausführen debuggen bzw. gibt es ein Tool, mit welchem man den "Excel Ausstieg" protokollieren könnte?

Mit meinem Code lässt sich der "Ausstieg" nicht mitschreiben, da der Code bis dahin beim "Ausstieg" gar nicht kommt:

ErrorExit:
Call LogMe(Me.name)
Call LogMe(Err.Number)
Call LogMe(Err.Description)

MsgBox "Fehler in >" & Me.name & "< Sub UserForm_Activate" & vbCrLf & _
"Fehlernummer: " & Err.Number & vbCrLf & _
"Fehlerbeschreibung: " & Err.Description, _
vbInformation, "Fehlermeldung"

Vielen Dank für eure Hilfe.

Gruß

Michael

Answer 1

Hallo Andreas,

ich komme jetzt endlich dazu etwas zu antworten. :-(

Vielen Dank für Deine Ansätze. Also die *.exd habe ich mal gelöscht.

Beim Kompilieren tritt innerhalb des VBA-Projektes kein Fehler auf.

Teste ich mein VBA-Projekt INNERHALB der Eintwicklungsumgebung, dann "raucht" das Excel nicht ab. Das Problem tritt nur auf, wenn ich mein Projekt ausserhalb der Entwicklungsumgebung starte. Aber nicht bei allen Teilen des Projektes.

Es ist nur speziell bei einer UserForm wenn ich diese aufrufe.

Mir ist aber etwas aufgefallen: Wenn ich innerhalb meines Projektes z.B. UserForm1 und dann den "." eingeben, dass erscheint doch immer so ein kleines Fenster, in welchem alle Möglichen Befehle auftauchen, die zu "UserForm1." passen und ausgewählt werden können. Erscheint dieses Fenster sofort, dann weiss ich, dass nach dem Koilieren, Speichern, Schließen und dann ausführen KEIN Fehler auftritt.

Dauert das zusammenstellen dieses kleinen Fensters sehr lange, dann tritt der Fehler beim Starten zu 100% auf.

Gruß Michael

Answer 2

Die Antwort auf alle Fragen: Nein, Geht nicht, Nein, ...

Ich schließe mal aus das ein Programmierfehler Deinerseits vorliegt. :-)

Ich würde als erstes mal eine Bereinigung machen.

http://www.appspro.com/Utilities/CodeCleaner.htm

Dann würde ich die temp. Dateien der Steuerelemente löschen:

Suche nach *.exd und lösche alles was er findet.

Dann ist die Frage ob Du irgendwelche Steuerelemente verwendest die nicht in der FM20.DLL drin sind.

Das Projekt zu kompilieren ist schon richtig, der Compiler braucht zusätzlichen Speicher und der ist rar.
Wenn Du es nicht machst, dann wird dies (bei Standard-Einstellung) im Hintergrund bei Bedarf gemacht.

Und da lauert heutzutage das Problem:

Wenn dieser Prozess gestört/unterbrochen wird, z.B. durch Virenscanner / Sicherheitstools, dann kann es Dir schon mal abstürzen. Sollte nicht, aber ...

Außerdem kommt hier das Problem das ggf. für VBA ggf. nicht genügend Speicher da ist ... sollte eigentlich einen RTE 35010 geben, aber ...

Mehr gibt es da IMHO nicht zu sagen.

Andreas.