Hallo,
ich habe in Excel-VBA (Excel 2003) ein Makro:
‚Private Sub Workbook_Open() …‘
Nun kann ich beim öffnen des Dokumentes angeben ob das Makro gestartet werden darf oder nicht.
Wie kann ich aber nun einen Stoppunkt zum debuggen setzen?
Bevor ich an den Quellcode komme, ist er längst gelaufen.
Gruß Rainer
Hallo Rainer,
setz eine Stop-Anweisung an die Stelle, an der du unterbrechen willst.
Gruß, Andreas
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Andreas,
setz eine Stop-Anweisung an die Stelle, an der du unterbrechen
willst.
Danke! Die kannte ich noch nicht.
Gruß Rainer
ich habe in Excel-VBA (Excel 2003) ein Makro:
‚Private Sub Workbook_Open() …‘
Nun kann ich beim öffnen des Dokumentes angeben ob das Makro
gestartet werden darf oder nicht.
Wie kann ich aber nun einen Stoppunkt zum debuggen setzen?
Bevor ich an den Quellcode komme, ist er längst gelaufen.
Hallo Rainer,
da es keine Parameter hat kannst du es wie eine beliebige andere Prozedur direkt mit F8 austesten oder Haltepunkt(e) setzen und F5…
Bei den anderen Ereigniscodes mußt du halt die Parameter mitangeben:
Private Sub Worksheet_SelectionChange(ByVal Target As Range)
MsgBox „huhu“
End Sub
Sub Test()
Call Worksheet_SelectionChange(Range(„A1“))
End Sub
Einen Haltepunkt zu setzen ist ja einfach, einfach links neben der Codezeile klicken…
Was viele nicht wissen, ich lange Zeit auch nicht, stoppt der Code an einem Haltepunkt oder durch den Debugger wegen eines Fehlers in irgendeiner Codezeile, so kann man wenn den Fehler erkannt hat im Code obendrüber den Code abändern und das gelbe Symbol links nach oben schieben, so daß dann der Code ab dieser Stelle nochmals durchlaufen wird.
Bei zeitaufwendigem langen Code spart man sich dadurch den Code abzubrechen , zu ändern und dann neu bis zu dieser Stelle laufen zu lassen.
Gruß
Reinhard
Hallo Reinhard,
einfach mal ‚Stop‘ in den Code zu schreiben ist mir nicht eingefallen. 
da es keine Parameter hat kannst du es wie eine beliebige
andere Prozedur direkt mit F8 austesten oder Haltepunkt(e)
setzen und F5…
Nur wie war mir nicht klar.
Bei den anderen Ereigniscodes mußt du halt die Parameter
mitangeben:Private Sub Worksheet_SelectionChange(ByVal Target As Range)
MsgBox „huhu“
End SubSub Test()
Call Worksheet_SelectionChange(Range(„A1“))
End SubEinen Haltepunkt zu setzen ist ja einfach, einfach links neben
der Codezeile klicken…
Bevor ich Excel offen habe, sehe ich den Code ja nicht und wenn ich ihn sehe, ist der Code schon gelaufen. Das war ja mein Problem.
Ist aber gelöst, das Problemchen gefunden (‚Input‘ statt ‚Line Input‘ geschrieben. ) und gelöst. Das Macro wird immer umfangreicher. Inzwischen ist die Tariflohntabelle mit drin. *gg*
Gruß Rainer
einfach mal ‚Stop‘ in den Code zu schreiben ist mir nicht
eingefallen.
Bevor ich Excel offen habe, sehe ich den Code ja nicht und
wenn ich ihn sehe, ist der Code schon gelaufen. Das war ja
mein Problem.
Hallo Rainer,
ich verstehe nicht ganz warum du unbedingt die Datei öffnen willst, ein Stop im Open-Erigniscode einabuen, Datei schließen und neu öffnen willst um dann ab dem Stop den Code zu testen!?
Den Open-Ereigniscode kannst du doch gleich testen wie von mir beschrieben. Warum der Umweg mit dem Stop?
Für mich macht Stop nur Sinn im Zusammenhang mit einer If-Abfrage oder gar einer #If-Abfrage im Code.
Naja, ehrlich gesagt habe ich Stop und End noch nie in einem Code benutzt *gg*
Ist aber gelöst, das Problemchen gefunden (‚Input‘ statt ‚Line
Input‘ geschrieben.
umfangreicher.
drin. *gg*
Dann vergiss nicht, wenn du mal z.B. den Namen des aktiven Druckers brauchst das nicht so zu schreiben:
MsgBox ActivePrinter
sondern so:
MsgBox ActiveCell.Parent.Application.ActivePrinter
das sichert den Job, denn alle Codezeilen so zu „verlängeren“ macht den Code schwer lesbar für einen Nachfolger
Welche Möglichkeiten man da hat siehst du an einem kleinen Beispielcode:
Sub tt()
Dim s
Set s = ActiveCell
End Sub
Dies mit F8 durchlaufen lassen bis der Set-befehl ausgeführt wurde, nun Ansicht–Lokalfenster, dort aufs Pluszeichen vor s klicken usw. usw.
In der Praxis benutze ich dieses Vorgehen, also Set auf ein Objekt zu setzen um dann im Lokalfenster nachzuschauen wie ich denn referenzieren muß um z.B. auf eine Eigenschaft des Ojects zugreifen zu können.
Denn die Intellisense, also eine Auswahlliste die erscheint wenn man einen Punkt eingibt, erscheint nicht immer, meist dann nicht wenn ich sie sehr gut gebrauchen könnte 
„Input“ und „Line Input“ machten mir auch schon zu schaffen. Habe mich seinerzeit gründlich mit beiden auseinandergesetzt, damals hätte ich dir genau sagen können wie sie sich unterscheiden.
Naja, lang her, ich glaube es hing mit der Auswertung von 0D und/oder 0A oder anderen Steuerzeichen in einer eingelesen Zeile zusammen daß sie gelegentlich, nicht immer, unterschiedliches einlesen.
Ich sollte mal dazu übergehen wenn ich solche Erkenntnisse herausgefunden habe mir diese auch aufzuschreiben )
Aber egal, zumindest weiß ich wenn Unerwartetes eingelesen wird wo ich zuerst schauen muß *gg*
Getreu dem Motto, Gefahr erkannt, Gefahr gebannt.
Gruß
Reinhard
Hallo Reinhard,
ich verstehe nicht ganz warum du unbedingt die Datei öffnen
willst, ein Stop im Open-Erigniscode einabuen, Datei schließen
und neu öffnen willst um dann ab dem Stop den Code zu testen!?
irgendwie muss ich wohl auf dem Schlauch stehen.
Den Open-Ereigniscode kannst du doch gleich testen wie von mir
beschrieben. Warum der Umweg mit dem Stop?
Hmmm, den Stoppunkt kann ich doch nur setzen, wenn ich den Code sehe. Dann ist er aber schon gelaufen und wird nicht noch einmal ausgeführt.
Für mich macht Stop nur Sinn im Zusammenhang mit einer
If-Abfrage oder gar einer #If-Abfrage im Code.Naja, ehrlich gesagt habe ich Stop und End noch nie in einem
Code benutzt *gg*Ist aber gelöst, das Problemchen gefunden (‚Input‘ statt ‚Line
Input‘ geschrieben.
umfangreicher.
drin. *gg*Dann vergiss nicht, wenn du mal z.B. den Namen des aktiven
Druckers brauchst das nicht so zu schreiben:MsgBox ActivePrinter
sondern so:
MsgBox ActiveCell.Parent.Application.ActivePrinter
das sichert den Job, denn alle Codezeilen so zu „verlängeren“
macht den Code schwer lesbar für einen Nachfolger
*gg* Das sichert meinen Job bestimmt nicht.
Das Projekt ist doch für Leute im Mutterkonzern, die keinen Code lesen können. Ich habe einen API-Aufruf drin, ‚PathFileExists‘, ich kenne hier Niemanden, der das versteht.
Welche Möglichkeiten man da hat siehst du an einem kleinen
Beispielcode:Sub tt()
Dim s
Set s = ActiveCell
End SubDies mit F8 durchlaufen lassen bis der Set-befehl ausgeführt
wurde, nun Ansicht–Lokalfenster, dort aufs Pluszeichen vor s
klicken usw. usw.In der Praxis benutze ich dieses Vorgehen, also Set auf ein
Objekt zu setzen um dann im Lokalfenster nachzuschauen wie ich
denn referenzieren muß um z.B. auf eine Eigenschaft des Ojects
zugreifen zu können.
Denn die Intellisense, also eine Auswahlliste die erscheint
wenn man einen Punkt eingibt, erscheint nicht immer, meist
dann nicht wenn ich sie sehr gut gebrauchen könnte
Das kenne ich. Das ist ein Grund, warum ich so ein Fan von ADO bin.
Da spricht die Intellisense nämlich auch nicht mit mir.
„Input“ und „Line Input“ machten mir auch schon zu schaffen.
Habe mich seinerzeit gründlich mit beiden auseinandergesetzt,
damals hätte ich dir genau sagen können wie sie sich
unterscheiden.
In meinem Fall war das ein tippfehler, kein Verständnisfehler.
Ich habe in das Textfile '0,0123" geprintet und wollte das mit Input lesen. dann bekomme ich natürlich eine Null und 123. Mit Line Input und CSng(text) wird daraus eine ‚0.0123‘.
Naja, lang her, ich glaube es hing mit der Auswertung von 0D
und/oder 0A oder anderen Steuerzeichen in einer eingelesen
Zeile zusammen daß sie gelegentlich, nicht immer,
unterschiedliches einlesen.Ich sollte mal dazu übergehen wenn ich solche Erkenntnisse
herausgefunden habe mir diese auch aufzuschreiben
Oder, wenn man es braucht, hier fragen. Das ist viel bequemer, da muss man den Zettel nicht suchen. *fg*
Aber egal, zumindest weiß ich wenn Unerwartetes eingelesen
wird wo ich zuerst schauen muß *gg*Getreu dem Motto, Gefahr erkannt, Gefahr gebannt.
Ja, genau. Aber ohne Debugger habe ich eben nur das Excel-File doppelt geklickt und die Meldung bekommen ‚lesen über das Dateiende hinaus‘, bevor das File offen war, ich einen Stoppunkt hätte setzen können.
Ohne Debugger habe ich die Ursache nicht gefunden.
Gruß Rainer
Excel Vba Ereigniscode testen, hier Workbook_Open
Hallo Rainer,
ich verstehe nicht ganz warum du unbedingt die Datei öffnen
willst, ein Stop im Open-Erigniscode einabuen, Datei schließen
und neu öffnen willst um dann ab dem Stop den Code zu testen!?irgendwie muss ich wohl auf dem Schlauch stehen.
dito, scheint ein breiter Schaluch zu sein, meine Schuhgröße 46 hat da auch viel Platz drauf
Den Open-Ereigniscode kannst du doch gleich testen wie von mir
beschrieben. Warum der Umweg mit dem Stop?Hmmm, den Stoppunkt kann ich doch nur setzen, wenn ich den
Code sehe.
Jepp. (Vba-Möglichkeiten zur laufzeit Codezeieln einzufügen lassen wir mal weg, schon verwirrend genug)
Dann ist er aber schon gelaufen und wird nicht noch
einmal ausgeführt.
Genau das meine ich doch und sehe das völlig anders, starte den Code einfach nochmal oder mehrmals mit F8
Und zum Testen von Worksbooks_Open-Code kannste den doch sowieso komplett aus dem Dokumentmodul der Arbeitsmappe entfernen und in einem normalen Modul nach Herzenslust testen und ersparst dir das jeweilige Datei öffnen.
Wenn er okay ist, wieder zurück in das Dokumentmodul der Arbeitsmappe.
Gruß
Reinhard
Hallo Reinhard,
Dann ist er aber schon gelaufen und wird nicht noch
einmal ausgeführt.Genau das meine ich doch und sehe das völlig anders, starte
den Code einfach nochmal oder mehrmals mit F8
es beginnt zu dämmern. Das versuche ich morgen mal, inzwischen bin ich zu Hause.
Danke!
Gruß Rainer