Office: (Office 2000) DoCmd.Close acForm, "Formular"

Hallo,

DoCmd.Close acForm, "Formular" verursacht auch dann keinen Fehler, wenn "Formular" nicht geöffnet ist. Ich weiß nicht, ob dieses Verhalten ein Zufall oder gewollt ist (Access 2000).
Natürlich könnte ich mit SysCmd(acSysCmdGetObjectState, .... den Status vorher prüfen, jedoch scheint dies nicht wirklich notwendig zu sein.

Spricht irgendetwas dagegen, auf SysCmd.... zu verzichten und einfach nur den Close-Befehl zu schreiben? Ich denke da z.B. an evtl. Unverträglichkeiten unter Access 2007. Hat jemand Erfahrungen diesbezüglich?

:)

 

... wo ist Dein Problem? Nach DoCmd.Close acForm, "Formular" kannst'e sicher sein, dass das Formular nicht mehr geöffnet ist, egal, ob es existiert, ob es geöffnet war oder nicht...

 

das ist schon klar. Ich meinte, ob Konfigurationen denkbar sind, bei denen es doch zu einem Fehler führt, wenn DoCmd.Close .... ein Formular schließen will, daß nicht geöffnet ist.

 

... nö...

 

ansonsten kann das so gut wie immer mit einem On Error Resume Next vor dem Close-Befehl ignoriert werden

 

[OT]

... immer diese "On Error Resume Next"-Programmierung. *wink.gif*

Ich halte das für eine große Gefahrenquelle, um später Logik-Fehler nicht mehr zu finden.
Was ist so schlimm wenn man zuvor prüft, ob eine später auszuführenden Anweisung überhaupt durchführbar ist?
Ok, im Beispiel von Docmd.Close acForm ist das nicht notwendig, doch möglich ist es allemal.
ab Ac2000: CurrentProject.AllForms("FormName").IsLoaded

Ich entwickle meine Anwendungen z.B. immer mit der VBA-Einstellung: "bei jedem Fehler anhalten"

[/OT]

 

\@Josef: Im Prinzip hast Du ja Recht. IA mache ich auch immer eine komplette Fehlerbehandlung, nur eben in ganz einfachen Fällen verzichte ich gern mal darauf; zumindest sofern es sich nicht auf andere Proc auswirkt und ein Fehler mitgeschleppt werden kann (ansonsten wird´s unlustig) *upps

 

Code:

...deren Freund ich leider auch bin. *wink.gif*
Allerdings schmeiße ich das Statement auch nicht einfach an den Anfang der Routine, sondern vor die betreffende Zeile, und schalte unmittelbar danach wieder die korrekte Fehlerbehandlung ein:
...
On Error Resume Next
Call FunctionWithPotentialErrror
On Error Goto Fehlerbehandlung
...

Soll nicht den erhobenen Zeigefinger von Josef relativieren!
Wenn es sinnvoll ist und ohne größenen Aufwand realisierbar, dann sollte so eine Bedingung schon vor dem zweifelhaften Aufruf stehen.

Ciao, Sascha

 

\@Smaug: ich meinte gar nicht eine komplette Fehlerbehandlung vs. Resume next, sondern ich finde eine Prüfung, ob eine Fehler auftreten kann besser, als später auf einen Fehler zu reagieren.
Wenn es auf Höchstgeschindigkeit ankommt, kann natürlich eine Fehlerbehandlung im Ausnahmefall schneller sein, als als eine Prüfung. Aber wer unter Access Höchstgeschwindigkeit erwartet setzt mit VBA das falsche Werkzeug für die Programmierung ein. *wink.gif*

Als Beispiel:
Code:

ich nutze lieber so etwas:
Code:

 

\@Sascha / Josef: Threads #8 + 9: genau auch meine Meinung !! *Smilie
Ich meinte das On Error Resume Next genau in dem von Sascha gezeigten Zusammenhang mit der speziellen Zeile

 

Hallo,
im Prinzip teile ich die Ansicht von Josef auch. Lieber vorher prüfen, als nachher auf einen Fehler reagieren.

Doch darum ging es mir garnicht. Meine Frage war im Grunde viel simpler gedacht. Hätte sie vielleicht besser formulieren sollen.
Ich wills daher nochmals mit anderen (etwas laienhaften) Worten versuchen.

Wenn die Tatsache, daß DoCmd.Close acform,"FormX" bei geschlossenem FormX keinen Fehler verursacht, ein "definiertes", gewolltes Verhalten ist, dann kann ich mir alle Prüfungen incl. Fehlerbehandlungstricks sparen, weil ich davon ausgehe, daß das in Nachfolgeversionen auch so ist.
Wenn der Fehler jedoch nur deshalb ausbleibt, weil die MS Programmierer diesen Fall übersehen haben und Access 'zufälligerweise' einfach mit der nächsten Zeile weiterarbeitet, dann würde ich vorher immer prüfen. Denn vielleicht sind spätere Versionen nicht so tolerant.

Würde z.B. in der Onlinehilfe der Satz stehen "Wenn Sie mit DoCmd.Close versuchen, eine nicht geöffnetes Formular zu schließen, tritt kein Fehler auf und Access fährt mit dem nachfolgenden Kommando fort", dann gäbe es diesen Thread nicht.
Sorry für die Haarspalterei. So wichtig ist das Ganze nun auch wieder nicht.

 

Diese Haarspalterei finde ich durchaus berechtigt.
Ich kann z.B. ein Recordset auch nicht schließen, wenn es nicht offen ist.
Somit verlasse ich mich zumindest bei solchen - mir "unlogischen" erscheinenden - Verhaltensweisen nicht darauf, dass das bei der Nachfolgeversion auch noch so ist.
z.B. wurde vor nicht zu langer Zeit hier im Forum aufgezeigt, dass Aktualisierungen von berechneten Feldern, die sich Werte direkt aus der Datenherkunft des Forms holen, nicht mehr sofort durchgeführt werden, wie bei den Vorgängerversionen. ... das könnte man jetzt als Bug bezeichnen, es kann aber auch passieren, dass dies zum "Feature" ernannt wird. *biggrin.gif*

 

Hallo Josef,
danke für Deine Hinweise. Ich werde die sicherere Variante wählen.
Zumindest habe ich mit CurrentProject.AllForms("FormName").IsLoaded wieder eine Alternative zu SysCmd(acSysCmdGetObjectState,...
Das hatte ich irgendwie vergessen.

 

Noch ein Tipp:
kapsel die Access-Methode in einer eigenen Sub. Dann kannst du später jederzeit etwas ergänzen.

z.B.:
Code:

 

gute Idee.
Ciao