Office: (Office 2003) LZF 91, Access hängt sich auf

Hallo zusammen,

ich baue mir grad ein Konstrukt mit einem Treeview und einem Listview und hantiere dabei auch mit Objektvariablen.

Leider hängt sich Access vollständig auf, wenn mir LZF 91, Objektvariable nicht definiert bzw. festgelegt gemeldet wird.

Ist das normal, das sich Access sofort aufhängt?
Ich muss Access dann über den Taskmanager beenden. Irgendwie lästig.

:)

 

Sind die Verweise auf die Active-X Komponenten korrekt eingebunden?

 

Wo hängt sich denn der Debugger auf?

 

\@Hans-Christian
meiner Meinung nach Ja. mir ist nur zwischenzeitlich eingefallen, das ich bei einigen Funktionen, an die ich ein Treeview oder Listview übergebe, diese Objekte einfach 'as Treeview' bzw. 'As Listview' deklariert habe, anstatt 'As MSComctlLib.ListView' bzw. 'As MSComctlLib.TreeView'. Könnte das ein Grund sein? Da ich den Fehler unterdessen ausgemerzt habe, läuft alles problemlos. Ich verstehe halt nur nicht, warum er bei Fehlermeldung mit Sanduhr stoppt. In Debugger komm ich ja garnicht erst rein *entsetzt *entsetzt *entsetzt

@Toast
Access hängt sich auf, nicht der Debugger.

 

Hallo Uwe,

das könnte nur dann ein Problem werden, wenn Du in Deinem VBA-Projekt noch weitere Objekte mit dem Namen Treeview oder Listview hast.

Durch die vollständige Deklaration machst Du VBA direkt klar, welche Bibliothek zu verweden ist und solche Probleme können gar nicht erst entstehen.

CU

 

Hallo Thomas...

Entsprechende Controls bekommen bei mir einen Präxix gefolgt von Einer Bezeichnung, die den Verwendungszweck deutlich machen soll. Bei mir zB tv_gruppen für Treeview, lv_befehle fürs Listview. Ich hab zwar mehrere Funktionen /Subs, wo ich das View im Parameter übergebe aber sie werden auch alle vor verlassen der Function/Sub auf Nothing gesetzt.
Außerdem habe ich die Deklaration in den Parametern geändert, Es wird jetzt direkt auf die MScomtlib-Dingsda verwiesen. Danach habe ich den Fehler nochmal provoziert und Access hat sich wieder auf gehangen.

Mal sehen, ob noch jemand ne Meinung hat, warum dieses Phänomen entsteht.

 

Hallo Uwe,

Ich habe mich unklar ausgedrückt. Mit Objekten meine ich nicht Steuerelemente sondern Klasse-Module.

Wie schon geschrieben ist das der sichere Weg. Du sagst Access bzw. VBA auf diesem Weg ganz genau, welches Objekt zu nehmen ist.

Ich dachte, das Problem sei gelöst. Wie hast Du es denn geschafft, dass Du den Fehler provozieren kannst?

CU

 

Ohne zu weit auszuholen. Ich brauche für meine aktuelle Anwendung DragDrop-Operationen, ohne das ich die Treeviewtypischen Maßnahmen anwenden. D.h. zB, wenn ich etwas auf ein Childknoten ziehe, sollen keine Unterchilds erzeugt werden, sondern die gezogenen Daten sollen hinter dem Zielchild eingefügt werden. Also Verschiebe -und Sortiervorgänge innerhalb eines Treeviews, eines Listviews und zwischen diesen beiden.

Wenn das Konstrukt gestartet wird, selektiert das Treeview den ersten Root. Sind Roots selektiert, soll das Listview keine Daten zeigen, diese sind ausschließlich den Childs zugeordnet.
Das ziehen eines Nodes aus dem Treeview in das leere Listview hat Fehler 91 ausgelöst. Ich habe die SUb zum Füllen des Listview dahingehend modifiziert, das bei Roots eine Dummyeintrag im Listview erzeugt wird. ZIehe ich nun ein Node in das Listview ist alles gut. Ich kann die Modifikation aber auch deaktivieren und schon habe ich wieder Fehler 91, da das Listview in dem Fall nicht befüllt und somit Nothing ist.

 

Hallo zusammen,

Ist in der Prozedur/Funktion, in der der Fehler auftritt, eine Fehlerbehandlung eingebaut?

Kann es sein, das du dort in einer (Endlos-)Schleife festhängst (Hilft vlt. STRG+Unterbr)?

 

Jede Prozedure hat eine Fehlerbehandlung und STRG+Pause bringt auch nix. Wäre ja schön wenn das ginge, dann wüsste ich ja, woran es liegt.

Was mir einfällt.... der zuletzt aufgetretene Fehler entstand innerhalb einer Drag-Drop Operation.
Im Treeview gedraggt und dann in das leere Listview gezogen und plopp. Zum droppen kommt er garnicht mehr.

 

Sollte noch jemand eine Idee haben, dann immer her damit.

Das Thema setzte ich aber auf erledigt, da die Fehlerursachen ja behoben sind.

 

Hallo Uwe,
es ist schwer nur anhand deiner Beschreibung den Fehler nachzuvollziehen,
da keiner weiß, wie deine Verschieberoutinen aussehen.

Vlt. kannst du ein Bsp. erstellen.

Zur Selbstanalyse: Setze einen Haltepunkt an den Anfang des Vorgangs
und hangel dich mit F8 (Einzelschritt) durch, bis der Fehler auftritt.

 

Hallo zusammen,

ich hole das Thema nochmal hoch. Ich habe nach wie vor das Problem, das sich Access komplett aufhängt, wenn ein Laufzeitfehler 91 ausgelöst wird. Ich werde deswegen allmählich tobsüchtig.
Zum gegenwärtigen Zeitpunkt wird der Fehler ausgelöst, wenn ein Node gedraggt aber noch nicht abgelegt wird, also in 'tv_gruppen_OLEDragOver'
Meine DB findet Ihr im Anhang. Vllt. könnte da mal jemand reinguggen.

Es geht mir NICHT darum, den LZF auszumerzen(das krieg ich schon alleine hin), sondern darum, die Ursache zu finden, warum sich Access aufhängt. Könnte das evtl. auch an meiner Installation liegen???

Wäre für Hinweise dankbar. Es stinkt einen an, bei manchen Fehlern erst Access abschiessen und neu starten zu müssen. Dafür ist der Debugger doch wohl da, das er mit die Codezeile mit dem Fehler anzeigt.

P.S: Mir fällt ein, das sich manche Fehlermeldungen des Debuggers nicht mit der Maus und Klick auf zB OK-Button sondern vielmehr nur durch Escape schließen lassen. Aber das waren Ausnahmen.

 

Hallo Uwe,

schon beim Start des Formulars gibt es die erste Fehlermeldung
"Sie haben als Einstellung der Ereigniseigenschaft..."
Treeview wird dementspr. nicht gefüllt.
Ein Kompilierversuch bringt ebf. diverse Fehler.
So kann man schlecht dein Problem testen *wink.gif*

[Edit] fehlt dem Beispiel vlt. ein Modul mit global definierten Variablen?

 

Moin Marsu,

ich hab das Problem aber nicht. Auch nicht mit der Datei, die ich hier hochgeladen habe. Startet einwandfrei. Es fehlt von meiner Seite auch nichts. Module müssen sein: frm_listviews; m_declare; m_views und clsDDO

Was genau besagt denn diese Fehlermeldung?

Ich hab eben mal alle Teile meines Beispiels in eine leere DB importiert. Da hatte ich beim Starten die Meldung. Benutzerdefinierter Datentyp nicht bekannt oder so. Ich musste den Verweis auf die CommonControls 6.0 neu setzen, danach konnnte ich das Form problemlos starten. Access hängt sich aber weiterhin auf.

Edith:
Ich habe nun noch eine leere DB erzeugt und die Inhalte des Beispiels per Copy/Paste übertragen, um evtl. korrupte Codecontainer auszuschließen. Insgesamt ohne Erfolg.

Mir ist aufgefallen: Sowohl in der, per Copy/Paste erzeugten Db als auch in einer leeren DB(nur ein Form ohne Inhalt, um an VBA dranzukommen) fehlt in der liste der Verweise der Eintrag 'Ms Windows Common Controls 6.0'. Ich meine das das da aber stehen sollte. Reparaturinstallation vom Office als auch händisches Registrieren der 'mscomctl.ocx' haben ebenfalls nichts gebracht. Ein hinzufügen der 'mscomctl.ocx' über druchsuchen ist aber möglich.
Was aber in den Verwiesen steht ist 'Ms CommonControls Satellite-3 6.0' Was hat es damit auf sich??? Bin leider ratlos. vllt. sollte ich mich Rudi nennen