Option "Unterbrechen bei Fehlern"
Michael Schüller
mir scheint, ich habe die im Betreff genannte Einstellung unter
"Extras - Optionen - Allgemein" nicht ganz verstanden.
Nehmen wir mal an, ich habe dort "Bei nicht verarbeiteten Fehlern"
gewählt.
Die Hilfe sagt zu dieser Einstellung:
"Sollte keine Fehlerbehandlungsroutine vorhanden sein, bewirkt der
Fehler, daß der Haltemodus für das Projekt aktiviert wird."
Nehmen wir weiter an, ich habe den folgenden Code
Sub test()
MsgBox CInt("a")
End Sub
Ich würde jetzt erwarten, dass bei Ablauf des Codes die fehlerhafte
(einzige) Zeile den Haltemodus aktivieren würde. Ist aber nicht so.
Der Fehler wird gemeldet (einverstanden) und die Ausführung
_abgebrochen_ (nicht einverstanden).
Warum kein Haltemodus? Es ist doch _keine Fehlerbehandlungsroutine
vorhanden_.
Kann mir jemand sagen, was ich da falsch verstanden habe?
Danke im Voraus &
schönen Gruß
--
Michael
michael....@gmx.de
Susanne Wenzel
ich habe Deinen Testcode mal bei mir ausprobiert...
> mir scheint, ich habe die im Betreff genannte Einstellung unter
> "Extras - Optionen - Allgemein" nicht ganz verstanden.
>
> Nehmen wir mal an, ich habe dort "Bei nicht verarbeiteten Fehlern"
> gewählt.
> Die Hilfe sagt zu dieser Einstellung:
> "Sollte keine Fehlerbehandlungsroutine vorhanden sein, bewirkt der
> Fehler, daß der Haltemodus für das Projekt aktiviert wird."
>
> Nehmen wir weiter an, ich habe den folgenden Code
>
> Sub test()
> MsgBox CInt("a")
> End Sub
>
>
> Ich würde jetzt erwarten, dass bei Ablauf des Codes die fehlerhafte
> (einzige) Zeile den Haltemodus aktivieren würde. Ist aber nicht so.
> Der Fehler wird gemeldet (einverstanden) und die Ausführung
> _abgebrochen_ (nicht einverstanden).
er meldete mir (Excel XP SP3) den Fehler und bot mir die üblichen
Schaltflächen an, ein Klick auf Debuggen und schon hatte ich die gelb
unterlegte Codezeile vor Augen.
Wie sieht denn Deine Fehlermeldung aus? Hast Du die Schaltfläche Debuggen
nicht dabei?
> Warum kein Haltemodus? Es ist doch _keine Fehlerbehandlungsroutine
> vorhanden_.
>
> Kann mir jemand sagen, was ich da falsch verstanden habe?
Ich versuchs zumindest ;-)
Viele Grüße aus dem hohen Norden Deutschlands
Susanne
Michael Schüller
erstmal Danke für Deine Antwort.
> er meldete mir (Excel XP SP3) den Fehler und bot mir die üblichen
> Schaltflächen an, ein Klick auf Debuggen und schon hatte ich die
gelb
> unterlegte Codezeile vor Augen.
>
> Wie sieht denn Deine Fehlermeldung aus? Hast Du die Schaltfläche
> Debuggen nicht dabei?
Die Fehlermeldung (XL 2000, 9.0.2812) lautet "Laufzeitfehler '13':
Typen unverträglich".
Angeboten werden die Schaltflächen "Ok" und "Hilfe".
Nach Klick auf "Ok" wird der Code ohne weitere Meldung abgebrochen.
>> Kann mir jemand sagen, was ich da falsch verstanden habe?
> Ich versuchs zumindest ;-)
Schön, dass Du Dich um mich kümmerst ;-)
Nochmal Danke & schönen Gruß
--
Michael
michael....@gmx.de
Susanne Wenzel
>> Wie sieht denn Deine Fehlermeldung aus? Hast Du die Schaltfläche
>> Debuggen nicht dabei?
>
> Die Fehlermeldung (XL 2000, 9.0.2812) lautet "Laufzeitfehler '13':
> Typen unverträglich".
> Angeboten werden die Schaltflächen "Ok" und "Hilfe".
das war auch meine Fehlermeldung, ich hatte jedoch noch die
Debuggen-Schaltfläche zur Verfügung. Gehe ich recht in der Annahme, dass
diese bei Dir zwar vorhanden, aber ausgegraut ist?
> Nach Klick auf "Ok" wird der Code ohne weitere Meldung abgebrochen.
Das wiederum ist logisch, Du hast ihm ja gesagt, dass dieser Fehler "in
Ordnung" ist (in ExcelXP heißt diese Schaltfläche auch sinnvollerweise
"Beenden")
>>> Kann mir jemand sagen, was ich da falsch verstanden habe?
>> Ich versuchs zumindest ;-)
>
> Schön, dass Du Dich um mich kümmerst ;-)
;-)
Das Fehlerverhalten von Deinem Programm kenne ich aus geschützten Modulen,
das wenden wir selber an, damit der Anwender nicht im Code herumfuhrwerken
kann...
Du hast Dein Makro von der Anwenderoberfläche gestartet?
Wie verhält es sich, wenn Du es aus der VBA-Umgebung startest, "fehlt" der
Button dann auch?
Wie sieht es beim Einzelschrittmodus aus?
Hast Du Dein Projekt mal kompiliert?
Befindet sich Dein Testcode in einer "frischen" Arbeitsmappe oder ist da
auch anderer Code vorhanden?
Bist Du servicepackmäßig auf dem neuesten Stand?
Zumindest schon mal eine Menge weitere Fragen...
Susanne
Michael Schüller
>> Die Fehlermeldung (XL 2000, 9.0.2812) lautet "Laufzeitfehler '13':
>> Typen unverträglich".
>> Angeboten werden die Schaltflächen "Ok" und "Hilfe".
>
> das war auch meine Fehlermeldung, ich hatte jedoch noch die
> Debuggen-Schaltfläche zur Verfügung. Gehe ich recht in der Annahme,
> dass diese bei Dir zwar vorhanden, aber ausgegraut ist?
Nein, sie ist erst gar nicht vorhanden.
> Das Fehlerverhalten von Deinem Programm kenne ich aus geschützten
> Modulen, das wenden wir selber an, damit der Anwender nicht im Code
> herumfuhrwerken kann...
Ich hatte bisher das geschützte Add-In "Eurotool.xla" eingebunden. Ich
dachte nach Deiner Beschreibung, dass das eventuell Auswirkungen auf
andere Module haben könnte. Aber auch nach Entfernen des Add-Ins und
Neu-Start von XL bleibt mein Problem bestehen. :-(
> Du hast Dein Makro von der Anwenderoberfläche gestartet?
Nein, nachdem ich das Problem festgestellt habe, habe ich das
gepostete Makro zu Testzwecken eingegeben und im VBA-Editor gestartet.
> Wie verhält es sich, wenn Du es aus der VBA-Umgebung startest,
> "fehlt" der Button dann auch?
S.o.
> Wie sieht es beim Einzelschrittmodus aus?
Habe ich auch probiert, s.o.
> Hast Du Dein Projekt mal kompiliert?
Nein. Geht das in XL?! Wenn ja, wie?
> Befindet sich Dein Testcode in einer "frischen" Arbeitsmappe oder
> ist da auch anderer Code vorhanden?
Frische Arbeitsmappe.
> Bist Du servicepackmäßig auf dem neuesten Stand?
Ja.
> Zumindest schon mal eine Menge weitere Fragen...
Hoffentlich helfen Dir meine Antworten...
Susanne Wenzel
ich habe mal ein bisschen nach Deinem Problem gegoogelt, aber nichts
vernünftiges gefunden, also muss ich meine eigenen Vermutungen anstellen...
>>> Die Fehlermeldung (XL 2000, 9.0.2812) lautet "Laufzeitfehler '13':
>>> Typen unverträglich".
>>> Angeboten werden die Schaltflächen "Ok" und "Hilfe".
>>
>> das war auch meine Fehlermeldung, ich hatte jedoch noch die
>> Debuggen-Schaltfläche zur Verfügung. Gehe ich recht in der Annahme,
>> dass diese bei Dir zwar vorhanden, aber ausgegraut ist?
>
> Nein, sie ist erst gar nicht vorhanden.
>> Du hast Dein Makro von der Anwenderoberfläche gestartet?
>
> Nein, nachdem ich das Problem festgestellt habe, habe ich das
> gepostete Makro zu Testzwecken eingegeben und im VBA-Editor gestartet.
>
>> Hast Du Dein Projekt mal kompiliert?
>
> Nein. Geht das in XL?! Wenn ja, wie?
Im VBA-Editor im Menü Debuggen der erste Menüpunkt ("Kompilieren von
VBAProject")
>> Befindet sich Dein Testcode in einer "frischen" Arbeitsmappe oder
>> ist da auch anderer Code vorhanden?
>
> Frische Arbeitsmappe.
>
>
>> Bist Du servicepackmäßig auf dem neuesten Stand?
>
> Ja.
Nachdem nun diverse Fehlermöglichkeiten abgeklappert sind, fallen mir noch
ein paar (leider wenige) Dinge ein:
Wie sieht es bei Deinen allgemeinen Excel-Sicherheitseinstellungen aus? (In
ExcelXP unter Makro -> Sicherheit...)
Ich habe in der KB von Microsoft einen Artikel gelesen, wonach eventuell
Probleme beim Umwandeln von Stringvariablen auftauchen können. Ich glaube
zwar nicht, dass das dort beschriebene Problem auf Deines passt, aber man
weiß ja nie... Nimm doch mal einen anderen Testcode, z.B.:
Sub test()
Dim b
Dim c
Dim d
c = 5
b = 0
d = c / b
MsgBox d
End Sub
Produziert auch zuverlässig einen Laufzeitfehler ;-)
Wie verhält sich Dein Programm, wenn Du im VBA-Editor bei den Optionen für
Unterbrechen bei Fehlern umschaltest von "Bei nicht verarbeiteten Fehlern"
auf "Bei jedem Fehler"?
Läuft bei Dir ein Virenscanner? Manche Probleme sind auf sowas
zurückzuführen. Wenn Du einen hast, schalte ihn mal testweise aus.
Überprüfe mal Deine gesetzten Verweise auf Gültigkeit, auch das ist ein
berüchtigtes Feld für manchen unerklärlichen Fehler.
Noch mehr Fragen und Ideen, leider kann ich Dir (noch?!) keine direkte
Problemlösung anbieten...
Susanne
Michael Schüller
> ich habe mal ein bisschen nach Deinem Problem gegoogelt, aber nichts
> vernünftiges gefunden
Habe ich auch gemacht, das Ergebnis war dasselbe...
Aber jetzt kommt ein neuer Ansatzpunkt (s.u.)...
>>> Hast Du Dein Projekt mal kompiliert?
>>
>> Nein. Geht das in XL?! Wenn ja, wie?
>
> Im VBA-Editor im Menü Debuggen der erste Menüpunkt ("Kompilieren von
> VBAProject")
Der Menüpunkt war bei meinem Dummy-Test-Code _deaktiviert_. Ich habe
mich gefragt, warum das so ist, und habe etwas rumprobiert.
Der Grund ist, dass der Code in einem _Sheet_ war und nicht in einem
_Modul_.
Verschiebe ich den Code in ein Modul, ist nicht nur der Menüpunkt
"Kompilieren" aktiviert, sondern der Fehler wird auch wie erwartet
behandelt, also _mit_ Schaltfläche "Debuggen"!
Dein alternativer "fehler-produzierender" Code zeigt das selbe
Verhalten.
Das heißt ja eigentlich, dass man (zumindest zur Entwicklungszeit) in
Sheets eigentlich keinen "Code", sondern nur "Aufrufe von
_Modul_-Code" verwenden sollte.
D.h. ich habe jetzt eigentlich die (neue) Frage, warum Code in Sheets
anders behandelt wird, als Code in Modulen.
Da das ein anderes Thema ist, werde ich einen neuen Thread "Code im
Sheet vs Code im Modul" aufmachen.
Aufgrund Deiner Antwort habe ich aber letztendlich zumindest eine
Möglichkeit gefunden, das Problem zu umgehen. Daher vielen Dank, dass
Du mir geantwortet hast. :-)
Schönen Gruß
--
Michael
michael....@gmx.de
Susanne Wenzel
> Aber jetzt kommt ein neuer Ansatzpunkt (s.u.)...
>
>>>> Hast Du Dein Projekt mal kompiliert?
>>>
>>> Nein. Geht das in XL?! Wenn ja, wie?
>>
>> Im VBA-Editor im Menü Debuggen der erste Menüpunkt ("Kompilieren von
>> VBAProject")
>
> Der Menüpunkt war bei meinem Dummy-Test-Code _deaktiviert_. Ich habe
> mich gefragt, warum das so ist, und habe etwas rumprobiert.
der Menüpunkt war meiner Meinung nach deaktiviert, weil seit dem letzten
kompilieren sich der Code nicht verändert hatte. Füge im Code im Sheet eine
neue Zeile hinzu, egal was und Du wirst feststellen, dass Du jetzt wieder
kompilieren kannst (bei mir ist das jedenfalls so).
> Der Grund ist, dass der Code in einem _Sheet_ war und nicht in einem
> _Modul_.
>
> Verschiebe ich den Code in ein Modul, ist nicht nur der Menüpunkt
> "Kompilieren" aktiviert, sondern der Fehler wird auch wie erwartet
> behandelt, also _mit_ Schaltfläche "Debuggen"!
> Dein alternativer "fehler-produzierender" Code zeigt das selbe
> Verhalten.
>
> Das heißt ja eigentlich, dass man (zumindest zur Entwicklungszeit) in
> Sheets eigentlich keinen "Code", sondern nur "Aufrufe von
> _Modul_-Code" verwenden sollte.
Du kannst auch dort die Schaltfläche Debuggen bekommen, Du müsstest dafür
nur in den Optionen beim Fehlerhandling entweder "In Klassenmodul" oder
"Bei jedem Fehler" anwählen (ebenfalls gerade getestet).
> D.h. ich habe jetzt eigentlich die (neue) Frage, warum Code in Sheets
> anders behandelt wird, als Code in Modulen.
> Da das ein anderes Thema ist, werde ich einen neuen Thread "Code im
> Sheet vs Code im Modul" aufmachen.
Frank hat Dir da ja schon geantwortet und Deine Beobachtung bestätigt. Ich
würde als Erklärung mal vermuten, dass die Ursache für das unterschiedliche
Verhalten in der Art des Moduls liegt, das "Sheet"-Modul ist ein
Klassenmodul und diese Sorte ist eine spezielle Sorte (diese Erfahrung habe
ich in VB gemacht ;-).
Susanne
Michael Schüller
>> Der Menüpunkt war bei meinem Dummy-Test-Code _deaktiviert_. Ich
>> habe
>> mich gefragt, warum das so ist, und habe etwas rumprobiert.
> der Menüpunkt war meiner Meinung nach deaktiviert, weil seit dem
> letzten kompilieren sich der Code nicht verändert hatte. Füge im
> Code
> im Sheet eine neue Zeile hinzu, egal was und Du wirst feststellen,
> dass Du jetzt wieder kompilieren kannst (bei mir ist das jedenfalls
> so).
Stimmt. Meine falsche Vermutung hat also zu einer richtigen Diagnose
(zumindest für mein Problem) geführt. Glück gehabt... ;-)
>> Das heißt ja eigentlich, dass man (zumindest zur Entwicklungszeit)
>> in
>> Sheets eigentlich keinen "Code", sondern nur "Aufrufe von
>> _Modul_-Code" verwenden sollte.
>
> Du kannst auch dort die Schaltfläche Debuggen bekommen, Du müsstest
> dafür nur in den Optionen beim Fehlerhandling entweder "In
> Klassenmodul" oder "Bei jedem Fehler" anwählen (ebenfalls gerade
> getestet).
Teilweise einverstanden.
Die Option "Bei jedem Fehler" würde den Code aber auch bei
"verarbeiteten" Fehlern stoppen. Eine Fehlerbehandlung per "On Error"
wäre also "für die Katz".
Klassen habe ich bisher nicht erstellt, aber die Option "In
Klassenmodul" würde wahrscheinlich zum selben Ergebnis führen, wenn im
entsprechenden Modul ein "behandelter" Fehler auftritt, oder?
Susanne Wenzel
man lernt doch nie aus ;-)...
>>> Das heißt ja eigentlich, dass man (zumindest zur Entwicklungszeit)
>>> in
>>> Sheets eigentlich keinen "Code", sondern nur "Aufrufe von
>>> _Modul_-Code" verwenden sollte.
>>
>> Du kannst auch dort die Schaltfläche Debuggen bekommen, Du müsstest
>> dafür nur in den Optionen beim Fehlerhandling entweder "In
>> Klassenmodul" oder "Bei jedem Fehler" anwählen (ebenfalls gerade
>> getestet).
>
> Teilweise einverstanden.
> Die Option "Bei jedem Fehler" würde den Code aber auch bei
> "verarbeiteten" Fehlern stoppen. Eine Fehlerbehandlung per "On Error"
> wäre also "für die Katz".
> Klassen habe ich bisher nicht erstellt, aber die Option "In
> Klassenmodul" würde wahrscheinlich zum selben Ergebnis führen, wenn im
> entsprechenden Modul ein "behandelter" Fehler auftritt, oder?
... und probieren geht über studieren;-)
(Weise Erkenntnisse und so völlig neu, nicht wahr? ;-)
Ich bin selbst ziemlich erstaunt, denn ich hätte genauso vermutet, aber von
wegen!
Ich habe gerade im Sheetmodul Code mit behandeltem Fehler unter der Option
In Klassenmodul ablaufen lassen und er ist brav in die
Fehlerbehandlungsroutine reingegangen und hat mir kein Debuggen-Fenster
gegeben...
Möglicherweise ist gerade diese Option die, die Du suchst. Musst Du
allerdings selber austesten, ob dem so ist.
Michael Schüller
> man lernt doch nie aus ;-)...
Ich weiß, wir sind hier nicht in de.rec.philosophie, aber ist das
nicht das Schöne am Leben...? ;-)
[...bisschen was gesnippt...]
>> Klassen habe ich bisher nicht erstellt, aber die Option "In
>> Klassenmodul" würde wahrscheinlich zum selben Ergebnis führen, wenn
>> im entsprechenden Modul ein "behandelter" Fehler auftritt, oder?
> ... und probieren geht über studieren;-)
> (Weise Erkenntnisse und so völlig neu, nicht wahr? ;-)
> Ich bin selbst ziemlich erstaunt, denn ich hätte genauso vermutet,
> aber von wegen!
>
> Ich habe gerade im Sheetmodul Code mit behandeltem Fehler unter der
> Option In Klassenmodul ablaufen lassen und er ist brav in die
> Fehlerbehandlungsroutine reingegangen und hat mir kein
> Debuggen-Fenster gegeben...
Im _Sheet-Modul_ habe ich das auch probiert. Meine Zweifel bezogen
sich aber auf ein "eigenes" Klassen-Modul. Da ich wie gesagt bisher
keine Klassen programmiert habe, frage ich mich, ob da eine
Fehlerbehandlung auch durchlaufen (also nicht zu einem Unterbrechen)
führen würde.
> Möglicherweise ist gerade diese Option die, die Du suchst. Musst Du
> allerdings selber austesten, ob dem so ist.
Habe ich derzeit auch so eingestellt. Ob es das Optimum ist, werde ich
wohl erst erfahren, wenn ich Klassen in meinen Code einfüge. Oder wenn
mir jemand sagt, wie das Verhalten in "eigenen" Klassen ist...
Danke für Deine Antwort