Office: Error Handling

Gibt es einen Weg festzustellen, ob eine Prozedur eine Event Prozedur ist?

Ich versuche per Code zu jeder Prozedur ein Error Handling zu erstellen.
Dabei stört mich, dass ich nicht unterscheiden kann, ob es sich um eine normale oder eine Event-Prozedur handelt.

Gibt es da eine Lösung?

Ein Gedanke wäre bei Formularen die Steuerelemente auszuwerten und ansonsten alle Variablen
mit dem "WithEvents" Keyword um abzuleiten ob das eine Event-Prozedur sein könnte.
Das gefällt mir aber nicht so gut.
Alternativ noch eine Erkennung durch die Namensgebung der Variablen in Klassenmodulen, ist aber auch nicht so prickelnd.

Gibt es auch einen Weg, ähnlich wie im Objekt-Explorer die Eigenschaften bzw. Events auszulesen, ohne die Registry und die privaten Klassen zu durchwühlen?

LG Markus

:)

 

Hallo Markus,
Vielleicht ein bisschen naiv, aber ich als Halbwissender würde in normalen
Prozeduren auf den Unterstrich im Namen verzichten. Dann sollte doch
Code:

alle EventProcedures aussortieren.
gruss ekkehard

 

\@ekkehard,
theoretisch natürlich richtig. Praktisch muss ich mich auf die Auswertung verlassen können. Wobei ich das jetzt teilweise schon mache.
Da ich in vielen Klassen-Modulen mit Event-Managern arbeite, benenne ich die immer gleich. Da orientiere ich mich bereits am Namen der Prozedur.

Wenn es keinen anderen Weg gibt, werde ich mit der Namensgebung experimentieren.

LG Markus

 

Na gut, bis zu der Tiefe, in die ich bis jetzt vorgedrungen bin, sind mir noch
keine Event Prozeduren begegnet, die keinen "_" im Namen hatten.

 

Nein, ich habe auch normale Prozeduren in Klassenmodulen mit "_".
Vermutlich aber wenige die Private sind.

 

Was ist denn denn der reale Hintergrund des ganzen? Bzw. wo hast du denn Probleme bei der "After"-Error-Behandlung?

 

\@Jan,
bei einer normalen Prozedur leite ich den Error (unabhängig davon ob ich den Error im Code erzeuge, oder ob es ein Laufzeitfehler usw. ist) an die aufrufende Prozedur weiter.
Wenn man das bei einer Event-Prozedur macht, dann kracht es.

 

Hallo Markus,

ich benutze Events mehr als oft. Hauptsächlich wenn ich ein Form als Instanz aufrufe. Des öfteren auch in Klassen für Formulare mit Unterformularen, da hier das aufrufen per Instanz nicht so recht funktioniert.
Was spricht dagegen einen eigenen Error-Handler für das Event zu benutzen? Was ich auch nicht nachvollziehen kann ist, dass es "kracht". Kannst du mir das etwas näher bringen was Du da genau meinst *Smilie

Viele Grüße
trekking

 

Es wird in der Praxis doch jeder Code durch ein Event gestartet. Sobald man einen Button drückt - wird ein Event ausgelöst.

Da gibt es dann das Standard Error Handling.
Wenn das bei einer Form Instanz fehlt (wenn das Form mit New erstellt wurde), und es kommt zu einem Error kracht es.
Dieses Event-Prozedur kann dann aber beliebigen weiteren Code aufrufen.
Kommt es in dieser weiteren Prozedur oder in einer beliebig in die Tiefe verschachtelten Prozedur zu einem Fehler um man wendet einfach dieses Standard Error Handling an, dann läuft der Code in der übergeordneten Prozedur einfach weiter.

Deswegen reiche ich den Error immer an die übergeordnete Prozedur weiter.
Bei der automatisierten Code Erstellung für den Error muss ich daher unterscheiden, ob es sich um eine Event-Prozedur handelt oder nicht unabhängig ob die Event-Prozedur von einer eigenen Klasse einem ActiveX oder einem Access Objekt stammt.

Ich schau mir jetzt aber grade diesen vbWatchdog an.
Mal sehen ob mich das überzeugt.

 

Hallo Markus,

ich meinte eigen definierte Events (z.B. public event formclose()) mit meiner Aussage *Smilie

Postest Du Deine Erfahrungen mit vbWatchDog. Würde mich auch interessieren.

VG
trekking

 

Es ist ja nicht relevant, woher die Events stammen.
Hast du das Problem verstanden?
Wie löst du das geschilderte Problem?

 

Hallo Markus,

irgendwie habe ich das Problem so nicht. In der Regel verwende ich in jeder Prozedur einen Error Handler.
Wenn ich Teile des Codes in subs auslagere dann benutze ich meist Funktionen mit Rückgabewert True/False. Diese besitzt einen eigenen Error-Handler, der keine Meldung ausgibt sondern die Errormeldung in einer Property/Variablen (je nachdem wo es zum Einsatz kommt) abspeichert. An der aufrufenden Stelle wird dann die Fehlermeldung ausgegeben.

Code:

Somit habe ich es übergeordnet im auslösenden Event und sehe aber anhand der Meldung wo der Fehler aufgetreten ist.

Hoffe das war so verständlich. Was benutze Du denn als Standard Error Handling?
Wenn bei mir der Code "weiterläuft" nach einem Fehler habe ich meist ein Event nicht richtig ausgelöst und es wird dann einfach übergangen.

Aber vielleicht verstehe ich auch nicht so richtig was du genau meinst. *Smilie

Viele Grüße
trekking

 

Nach dieser Meldung musst du dann im aufrufenden Code ja was unternehmen, damit er nicht weiter läuft.

Jetzt könnte es aber noch 10 übergeordnete Prozeduren geben, die ebenfalls weiterlaufen, wenn du nichts tust und du willst den Fehler ja nur einmal sehen und nicht 10 mal.

Und was machst du da?

Wenn es keine saubere Lösung gibt, dann endet diese Annahme im Chaos.

 

Hallo Markus,

die 10 übergeordneten Prozeduren sind ja bei mir in der Regel auch funktionen die einen Bollean wert zurückgeben. Das wird also dann hoch Kaskadiert. Bei untergeordneten Funktionen ohne MsgBox, diese zeige ich erst bei der auslösenden Prozedur.

Gibt die "unterste" Funktion False zurück, dann sind alle anderen bis zur auslösenden Prozedur ja auch False. Das Kaskadier sich dann schön hoch.

Nur bei einem Fehler wird ja was in der Property gespeichert und somit zeigt mir die auslösende Prozedure die MsgBox mit dem Fehler.

Funktioniert selbst wenn Du zwischendrin Transaktionen ausführst ohne Chaos zu veranstalten.

Der Code sieht also in der Regel so aus:
Code:

Mit Fehlermeldung
Code:

In dem Teil kannst Du auch noch anderen Code verstecken, wie zum Beispiel das Schließen einer Excel-Instanz damit nicht unnötige Instanzen auf dem Rechner rumgeistern *Smilie

VG
trekking

 

Alles klar, habs zuerst falsch verstanden.

Mit dem Error Handling mache ich funktional nichts anderes.

Bei einem Error wird, wird eine Prozedur verwendet.
Darin wird dann eine Msgbox mit dem Fehler angezeigt.
Es gibt dann die Möglichkeit der Protokollierung und in einer accdb Version kann via msgbox der Debug Modus aufgerufen werden.

So lange man sich nicht in der Event-Prozedur befindet, wird ein Neuer Fehler mit einer speziellen Error Nummer ausgelöst, der dann nicht mehr angezeigt wird. Somit wird dann in jeder Prozedur die Verarbeitung gestoppt, außer es wird durch Programmierung umgangen.

Die eine Zeile für das Errorhandling im Rumpf und die "On Error Anweisung" lasse ich dann automatisiert erstellen. Ich programmiere also grundsätzlich direkt in der Prozedur nichts für das Error Handling.