Office: (Office 2003) Laufzeitfehler 2501: Die Aktion OpenForm wurde abgebrochen

Hallo, ich mal wieder.
Ich kriege gerade eine mittelstarke Krise. Und zwar überprüfe ich in einer Tabelle nach ob der gerade ans System angemeldete Anwender das Formular öffnen darf. In jedem Formular wird das dann so festgelegt: Code:

Die Funktion liefert True, wenn die Rechte für den Anwender nicht definiert werden konnten, oder ihm die Rechte dazu fehlen. Ich hab die Formulare schon über die Varianten Code:

geöffnet. Bei beiden das selbe Ergebnis. Nachdem ich dann eine neue Datenbank erstellt habe, und alle Objekte importiert habe, hatte ich dann die Fresse voll.
Weiß jemand weiter?

:)

 

Hi,

Wenn du Openform abbrichst, gibt es diesen Fehler. Du sagst doch eben: Cancel = true.


Ansonsten: sind da irgendwelche Kriterien im Spiel? Die Meldung kommt z.B. auch dann, wenn du technisch unzulässige Kriterien ansetzt (Datumsfeld = "Hallo").

 

Technisch unzulässige Kriterien sind mir da nicht aufgefallen. Cancel ist vom Typ Integer und mit setFormRights liefere ich einen Boolean zurück. Von daher bleibt mir da nur noch die doofe Frage: Soll ich da jetzt überall ein Code:

hinpacken?

 

Eine Fehlerbehandlung gehört grundsätzlich in jede Prozedur *wink.gif*
Bist Du den Code für setFormRights mal in Einzelschritten durch und hast geprüft ob der richtige Wert zurück kommt?

Wenn hier ein True erscheint, denke ich kommt eben das Cancel zu Stande und dann erscheint entsprechend die Meldung.

Ich würde ggf. vorher ansetzen und den Aufruf des Forms gar nicht erst ermöglichen.
Wozu versuchen eine Tür zu öffnen, wenn ich schon weiß dass der Schlüssel nicht paßt *wink.gif*

 

Hmm, ja meine Funktion setFormRights gibt schon den richtigen Wert zurück. Ich hätte mir jetzt eigentlich von der OpenForm-Prozedur gewünscht, dass es ihr eigentlich egal ist, ob das Formular geöffnet wurde oder ob das Öffnen abgebrochen wurde.

Wie der unglücklich gewählte Name setFormRights verrät, ist die Funktion für mehrere Dinge zuständig: Sie ermittelt gleichzeitig die Rechte am Formular und den Controls. Und wenn etwas gefunden wurde, dann werden auch sofort die Rechte gesetzt. Sowohl Formular- als Steuerelement-Rechte können optional gesetzt werden. Und wenn beides nicht gefunden wurde, dann wird das Formular auch nicht geöffnet.

 

Naja, aber diese Prüfung könnte doch auch schon der Aufrufer machen, statt der Aufgerufene.

Oder du lässt Form_Open fehlertolerant arbeiten: On Error Resume next. Aber das ist EDV brutal...

 

Sorry, dass ich von meinem eigenen Thema abdrifte, aber mit "On Error Resume Next" wollte ich auch gestern arbeiten. Hat irgend wie nicht so geklappt. Und zwar habe ich folgende Funktion gebaut: Code:

 

Bring mal deine Codetags in Ordnung. Das kann keiner lesen! *eek.gif*

 

Jo, ist mir dann auch aufgefallen. *schäm*

 

So, Wrapper-Prozedur für DoCmd.OpenForm habe ich geschrieben. Habe die jetzt auch ganz doof openForm genannt. Ich spreche sie über ComVersion.openForm an.
Ich hoffe mal, dass ich da nicht in Konflikt mit der Original-Funktion gerate.

Edit: Das Projekt lässt sich sowas von überhaupt nicht mehr kompilieren!

 

Dann ist der Wurm drin.

Wenn du die Sub mit Modulnamen ansprichst, sollte das kein Problem sein.

 

Jo, das läuft jetzt wieder alles wunderbar.

Hmm, da ich jetzt die eine Wrapper-Prozedur habe, könnte ich ja im Prinzip auch die von euch vorgeschlagene Änderung bei den Rechten in Angriff nehmen. Denn dank der Wrapper-Prozedur muss ich nur noch an einer Stelle den Code anpassen, nicht mehr bei jeder Aktion, die ein Formular öffnet.
Die Frage ist dann jetzt nur noch, wie ich das derart effektiv hinkriege, dass ich für das Überprüfen und das Setzen der Formularrechte nicht die Tabellen für Formular- & Steuerelement-Rechte zweimal öffne.
Ich könnte die RecordSets in der Wrapper-Prozedur öffnen und dann als Parameter übergeben.

 

Ich würde für die Rechte etc. eine eigene Klasse schreiben, welche beim Start der Anwendung instanziert wird.
Die Klasse weiß dann für ihre Lebenszeit, welche Rechte der User mit dem sie instanziert wurde hat.

Der Zugriff auf die entsprechenden Werte/Properties der Klasse ist dann deutlich eleganter wie ein wiederkehrender Zugriff auf Tabelle/RecordSet.

 

Hmm, auch eine Möglichkeit. Vom Speicherverbrauch sollte das eigentlich gehen: Ich habe bisher 82 Datensätze für die Steuerelemente und 43 für die Formulare.

 

Ich nochmal.
Das Konzept, dass das Formular selbst überprüft, ob es sich öffnen darf, halte ich bisher für ganz akzeptabel. Hat vor allem damit zu tun, dass mehrere Formulare mal als normales Formular geladen werden und mal auch als Unterformular. Hier habe ich dann wieder Anpassungen gespart.