PDA

Vollständige Version anzeigen : LZF 91, Access hängt sich auf


Storch
09.06.2012, 07:13
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.

hcscherzer
09.06.2012, 08:42
Sind die Verweise auf die Active-X Komponenten korrekt eingebunden?

Toast78
09.06.2012, 09:00
Wo hängt sich denn der Debugger auf?

Storch
09.06.2012, 09:13
@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.

Thomas Möller
09.06.2012, 09:26
Hallo Uwe,

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?

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

Storch
09.06.2012, 12:08
Hallo Thomas...

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

Thomas Möller
09.06.2012, 12:15
Hallo Uwe,
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.

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

Außerdem habe ich die Deklaration in den Parametern geändert, Es wird jetzt direkt auf die MScomtlib-Dingsda verwiesen.

Wie schon geschrieben ist das der sichere Weg. Du sagst Access bzw. VBA auf diesem Weg ganz genau, welches Objekt zu nehmen ist.
Danach habe ich den Fehler nochmal provoziert und Access hat sich wieder auf gehangen.

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

CU

Storch
09.06.2012, 14:37
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.

Marsu65
09.06.2012, 15:21
Hallo zusammen,
Ich verstehe halt nur nicht, warum er bei Fehlermeldung mit Sanduhr stoppt.
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)?

Storch
09.06.2012, 16:11
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.

Storch
11.06.2012, 09:45
Sollte noch jemand eine Idee haben, dann immer her damit.

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

Marsu65
11.06.2012, 14:53
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.

Storch
06.07.2012, 19:32
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.

Marsu65
06.07.2012, 20:40
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 ;)

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

Storch
07.07.2012, 05:53
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

Storch
07.07.2012, 11:32
Zwischenstand...

nachdem ich die Funktionalität, die ich noch wollte eingebaut habe, hab ich mein Handling der Objektvariablen überarbeitet.
Im Moment hat es den Anschein, als das ich da irgendwas falsch gemacht habe. Abschließend kann ich das aber noch nicht sagen. Ich werde Bericht erstatten.

Marsu65
07.07.2012, 12:33
Zwischenstand:

Ich habe gerade den Verweis auf die Comoncontrols gelöscht und neu gesetzt.
Nun öffnet sich das Form erst mal fehlerfrei und der Kompiler läuft durch.

Später mehr ...

[Edit]
Kannst du noch einmal genau sagen, wie du dein Acc zum Absturz bringst.
Ich bekomme zwar Msgboxen mit Fehlermeldungen aber abstürzen tut nix. :)
Oder ist dieser Fehler, wenn er unbehandelt bleibt, die Ursache?

Vlt. kannst du auch noch einmal kurz die Funktionalität erläutern.
Denn ich kann von links nach rechts et vice versa ziehen, ohne das sich am Tree oder der Liste etwas verändert.

Storch
07.07.2012, 14:31
Ich hänge zunächst mal eine überarbeitete Version an. evtl. musst Du den Verweis auf Common Control 6.0 wieder nachrüsten.
Erläuterungen findest Du in der *.doc-Datei
Für erlaubte bzw. unerlaubte DDO’s siehe Excel-Tabelle
Beziehungen siehe Grafik

Die Modifizierung meiner Objektvariablen brachte keinen Erfolg. Zwar hatte ich während des Umbaus diverse LZF 91 aber diese ließen sich alle deguggen.

Der Knackpunkt , der Access wieder crashen lässt, befindet sich im Ereignis tv_gruppen_OLEDragOver. Such dort die Zeile , die mit 'Hier 91' beginnt und aktiviere den Debug.Print-Abschnitt.
Offensichtlich hat nicht jedes Node auch einen Next-Node und das bringt wohl den Fehler.
Das mit dem Next war auch nur ein Versuch und wird nciht mehr gebraucht, aber es löst halt bei mir den Fehler aus und crasht Access.

Ich hoffe, das DU mit den Erläuterungen klar kommst

Edith: Nach dem Aktivieren des Debug.Print-Abschnittes dragge im Treeview einen Root-Node und ziehe ihn hin und her ohne loszulasen. Dann sollte der Fehler kommen

Marsu65
07.07.2012, 23:17
Ok, in dem Bsp. lässt sich was bewegen. :D
Ich schaffe es auch einen Fehler zu provozieren.
Allerdings nur wenn ich (bestimmte?) Befehle verschiebe.
Es poppt die Msgbox mit der Fehlermeldung auf, und die Eieruhr hinterlässt den Eindruck, Acc sei eingefroren (ich gehe davon aus, dass das der Punkt ist, der bei dir zum finalen Ende führt).
Nach Druck auf die ESC-Taste geht´s jedoch ganz normal weiter.
Aber ich scheine auch ein außerordentlich stabiles Office zu besitzen :)

Falls es für dich noch relevant ist oder noch einmal wird:
Du kannst mit der LastSibling-Eigenschaft feststellen, ob der Knoten der Letzte (Kind-) Knoten ist und den Fehler im vorhinein vermeiden.
If nodItem = nodItem.LastSibling Then
'Knoten ist letzter Knoten
'tu nichts
Else
'nächster Knoten
Set nodItem = nodItem.Next
'tu was mit dem nächsten Knoten
End if

Storch
08.07.2012, 02:53
Ok, in dem Bsp. lässt sich was bewegen. :D
Wäre doch schlimm, wenn nicht :upps:

Es poppt die Msgbox mit der Fehlermeldung auf, und die Eieruhr hinterlässt den Eindruck, Acc sei eingefroren (ich gehe davon aus, dass das der Punkt ist, der bei dir zum finalen Ende führt).
Nach Druck auf die ESC-Taste geht´s jedoch ganz normal weiter.
Aber ich scheine auch ein außerordentlich stabiles Office zu besitzen :)
Letzteres scheint mir dann wohl zu fehlen :(
Wie ich erwähnte, hatte ich auch Fehlersituationen, aus denen ich mit Escape raus kam. Aber beim 'finalen Ende' eben nicht mehr. Mit welcher Accessversion hast DU getestet? Ich gedenke das Beispiel mal bei einem Freund zu installieren und dort zu gucken, wie es sich verhält. Allerdings hat der Acc07.

Stellt sich mir die Frage, ob das beschriebene Verhalten das Beispiel bzw. die spätere Anwendung, wo das Beispiel integriert werden soll, evtl. instabil machen könnte oder ob ich mit derlei Huddeleien nicht rechnen muss, solange keine Fehler auftreten.

Falls es für dich noch relevant ist oder noch einmal wird:
Du kannst mit der LastSibling-Eigenschaft feststellen, ob der Knoten der Letzte (Kind-) Knoten ist und den Fehler im vorhinein vermeiden.

Danke für den Hinweis. Ich hatte, was in der zweiten Variante schon wieder fehlt, das Next-Object mit IsNothing überprüft und nur bei false dann die Debug.Print-Aktion aufgerufen. Da gab es dann auch keinen Fehler mehr.

Danke für Deine Bemühungen. Sollte ich noch zu weiteren Erkenntnissen kommen, werde ich das posten.

Marsu65
08.07.2012, 12:54
Mit welcher Accessversion hast DU getestet?
Acc 2003 SP2 (11.6566.8132)

Storch
08.07.2012, 16:26
Ich hab Access 2003 (11.8321.8341) SP3

Storch
09.07.2012, 07:25
Jetzt falle ich wirklich vom Glauben ab.

Habe das Beispiel nochmal modifiziert und wieder einen LZF91.

Ich habe versucht, einen Item aus dem Listview einem anderen Child zuzuordnen. Diese DDO ist so vorgesehen.

Abgesehen das Access wieder tschüss sagt hab ich jetzt nacheinander Haltepunkte gesetzt, um zu sehen, an welcher Stelle der Fehler auftritt und Access aussteigt.

Das gedraggte Item hatte als Text-Eigenschaft den Inhalt 'texture'.

In meiner Fehlerbehandlung des Ereignisses 'lv_befehle_OLEStartDrag' steht 'texture' plötzlich hinter Case Else.. siehe Codebeispiel, roter Text.

Select Case Err.Number
Case Elsetexture
MsgBox "Admin sagt Fehler in Form_frm_views/lv_befehle_OLEStartDrag " & Err.Number
Resume Next
End Select


Das kann doch nicht normal sein, das Inhalte eines Controls plötzlich im Code landen?

Edith:
Während ich weiter degugge, per Einzelschritt, entsteht plötzlich folgendes:

'aktuell unter Mauszeiger befindliches Item kennzeichen
Set oListVitextureew.DropHighlight = oListView.HitTest(x, y)


Ich meine, wenn so ein Scheiss zur Laufzeit passiert, dann wundere ich mich garnicht, wenn Access aussteigt

Josef P.
09.07.2012, 08:07
Hallo!

Das kann doch nicht normal sein, das Inhalte eines Controls plötzlich im Code landen?

Solange du den Text nicht per Sendkeys o. ä. überträgst, ist das nicht normal. ;)

mfg
Josef

Storch
09.07.2012, 08:27
SendKeys verwende ich nicht.

Aber selbst damit, wie können Dateninhalte in den VBA-Code gelangen??? Das sollte eigentlich überhaupt nicht gehen. :boah: :boah: :boah:

Die Inhalte meiner Nodes und Items landen in Membervariablen einer Klasse zur Weiterverarbeitung. Aber das kann doch wohl auch kaum der Grund sein

Josef P.
09.07.2012, 08:28
Hallo!

Irgendwelche Kopoeiraktionen über die Zwischenablage machst du auch nicht, oder?
Ist das Verhalten reproduzierbar?

mfg
Josef

Storch
09.07.2012, 08:37
Auch nix mit dem Clipboard.

Reproduzierbar = JEIN

Ich hab Probleme(deswegen der Threed) das mir Access abkackt, bei LZF 91 ,,, objektvariable nicht festgelegt.

Das sich der Inhalt der Texteigenschaft in den Code einfügt, passiert, wenn ich versuche, den Fehler per Einzelschritt zu debuggen. Es ist nur nicht so einfach, gerade in OLEDragOver zu debuggen. Das einfügen des Textes scheint willkürlich zu geschehen. Mal hier mal dort.

Ich hab aber gerade Temaviewer zugang zu einem Rechner mit Acc2007 bekommenn. Will erstmal mein Beispiel dort testen. Vllt bringt das ja neue Erkenntnisse

Edith: Also Acc2007 hängt sich genauso auf. Von daher dürfte es nicht an meiner Accessinstallation liegen

Claypool
09.07.2012, 18:44
Hallo Uwe!

Ich habe Access2010 und kann den Fehler aus #18 nicht nachstellen. Kannst du nochmal eine DB hier einstellen, bei der der Fehler auftritt und kurz erläutern, was du gemacht hast? Danke!

Grüße
Ingo

Storch
09.07.2012, 20:13
Hallo
in der DB im Anhang ist der Fehlerauslöser aktiv und befindet sich im tv_gruppen_OLEDragOver.
Du kannst auch nach folgendem Kommentar suchen: 'Fehlerauslöser

Um ihn auszulösen dragge ich einen Rootnode und ziehe ihn hin und her. Noch vor dem loslassen kommt der Fehler.
Ich will aber nur noch wissen, wie sich Dein Access dann verhält. Der Code selber ist an sich nciht mehr relevant

Claypool
09.07.2012, 22:43
Hallo Uwe!

Ich habe jetzt mehrere Male den obersten Node angefasst und gehalten und nach oben/unten, links/rechts und kreuz/quer innerhalb, außerhalb des Fenster mit der linken Mausteste bewegt und konnte keinen Fehler produzieren.

Im Debugfenster kann man das hier nachlesen (in wesentlicher größerer Menge):
Fahrrad:
Fenster:
Schuppen:
ssss:
Turm:
Zaun:
Tanke:
Wohnhaus:
Sandungsturm:
Wasserkran:
[usw]

Die Verweise sehen so aus.

Ich kann keinen Fehler provozieren. Ist das jetzt gut oder ist das schlecht?
Vielleicht mache ich beim Test auch was falsch?

Grüße
Ingo

Josef P.
10.07.2012, 07:57
Hallo!

Ich kann den Fehler nachstellen, wenn ich die VBA-Option "Bei jedem Fehler unterbrechen" aktiviere.

/edit: ich sah mir den Code einmal an, obwohl er für mich nicht besonders übersichtlich gestaltet ist. ;)
Der Fehler liegt bei: <code>s = objDropHighlight.Next.Text</code>
Wenn objDropHighlight.Next nothing ist, wird das bei aktivierter Fehlerbehandlung abgefangen und übergangen.
Schöner wäre meiner Meinung nach folgende Variante:

Dim NextNode As Node
Set NextNode = objDropHighlight.Next
If NextNode Is Nothing Then
Debug.Print "objDropHighlight.Next is nothing"
Else
s = NextNode.Text
Debug.Print s
End If


mfg
Josef

Storch
10.07.2012, 10:13
@Ingo... der oberste Node und seine Childs dürfen garnicht gedraggt werden, das wird verhindert

@Joseph...
ist übersichtlich nicht auch ein bischen relativ??? und hängen Codes nicht ein wenig davon ab, welches Problem man lösen will und wie man es abstrahiert???

Ich habe leider keine Ahnung, wie ich es besser machen könnte. Ich hab IMHO schon so viel wie möglich gekapselt, hab in diesem Beispiel meine erste KLasse realisiert.

Zum Fehler:
Ich weiss, wo der Fehler liegt. Ich weiss auch, wie man den ausmerzt, denn ich habe es ja schon getan. Die Zeile mit der Next-Eigenschaft (war ursprünglich nur ein Versuch) hab ich nur nochmal in das Beispiel eingebaut, damit überhaupt ein Fehler 91 ausgelöst wird, denn:

Ich möchte doch nur wissen, warum sich Access aufhängt

Das so ein Fehler die Ursache ist, ist mir klar. Aber das der Debugger zwar den Fehler meldet, aber Access mit der Meldung einfriert kann doch nicht normal sein.

Um es für mich zu testen und für Euch geneigten Helfer die Sache doch zu vereinfachen, habe ich ein abgespecktes Beispiel konstruiert. Siehe Anhang.
Das Beispiel hat nur das Treeview im Form und im Modul ist nur Code zum füllen desselben aktiv, was in Form_Load ausgelöst wird.
Weiterhin im Formularcode die Ereignisse für Drag-Drop. Der Fehler kann provoziert werden, wenn in OLEDragOver die Zeile:
Set oDropHighlight = oTreeview.HitTest(x, y)
auskommentiert wird. Diese Objektvariable ist dann im weiteren Code nicht mehr verfügbar, obwohl sie dort gebraucht wird und logischerweise führt das zu dem Fehler.

Bei mir hängt sich Access wiederum auf, was mir zumindestens zeigt, das der ganze zusätzliche Code aus meinem ursprünglichen Beispiel nicht die Ursache für dieses Verhalten sein kann.

Achja: Bei mir ist ebenfalls 'Unterbrechen bei jedem Fehler' aktiviert. Die einzige Möglichkeit, Access nicht zum Absturz zu bringen ist, 'Unterbechen bei unbehandeltem Fehler' zu aktivieren, Fehler 91 explizit in die Fehlerbehandlung aufzunehmen und diese mit 'Resume Raushier' abzuschließen. Eine Messagebox vor Resume hängt Access auch auf.

Josef P.
10.07.2012, 11:04
Hallo!

/edit:
Beim Beispiel kommt es bei mir zu einer normalen Fehlermeldung aber zu keinem Absturz.
Allerdings muss man die Fehlermeldung das erste Mal per Tastatur bedienen. Die Maus scheint deaktiviert zu sein.
... das passt aber irgendwie sogar, da die Maus zu diesem Zeitpunkt eigentlich für Drag&Drop genutzt wird.

[OT]
Ist übersichtlich nicht auch ein bischen relativ?
Relative vielleicht nicht aber subjektiv.
Dein Code war für mich sehr schwer zu lesen, da zwischen den Funktionen kein Abstand war und ich somit nicht auf einen Blick das Ende erkennen konnte. Hätte mich das Verhalten nicht interessiert, hätte ich die Beispiel-DB nur kurz geöffnet und gleich wieder geschlossen. ;)

Als Beispiel:
...
tv_gruppen_OLEDragOver_Raushier:
Exit Sub
tv_gruppen_OLEDragOver_Problemlöser:
Select Case Err.Number
Case 91
'MsgBox "Fehler 91"
Debug.Print "Fehler 91"
Resume tv_gruppen_OLEDragOver_Raushier
Case Else
MsgBox "Admin sagt Fehler in Form_frm_views/tv_gruppen_OLEDragOver " & Err.Number
Resume Next
End Select
End Sub
Private Sub tv_gruppen_OLEDragDrop(Data As Object, Effect As Long, Button As Integer, Shift As Integer, x As Single, y As Single)
On Error GoTo tv_gruppen_OLEDragDrop_Problemlöser
MsgBox "DDO fertig"
tv_gruppen_OLEDragDrop_Raushier:
If Not oTreeview Is Nothing Then Set oTreeview = Nothing
If Not oDropHighlight Is Nothing Then Set oDropHighlight = Nothing
Exit Sub
tv_gruppen_OLEDragDrop_Problemlöser:
Select Case Err.Number
Case Else
MsgBox "Admin sagt Fehler in Form_frm_views/tv_gruppen_OLEDragDrop " & Err.Number
Resume Next
End Select
End Sub
Das wirkt für mich nicht übersichtlich.

mfg
Josef

Storch
10.07.2012, 11:20
Hallo Joseph,

hast DU denn auch die benannte Zeile deaktiviert? Und natürlich muss man dann auch draggen, damit der Fehler kommt. Aber ich denke das ist Dir von selbst klar.

ich hänge das Beispiel aber nochmal an. In diesem ist die Fehlerquelle aktiv.

Jetzt verstehe ich, worauf sich Dein 'unübersichtlich' bezieht und ich muss Dir da zustimmen. Mir hat das so immer gereicht, da ich ja auch weiss, worum es geht und ich ja nahezu überall Kommentare zwischen habe.
Ich werde Deine Kritik aber zukünftig berücksichtigen, insbesondere zwischen Codeblöcken Leerzeilen einbauen.

Josef P.
10.07.2012, 11:31
Hallo!

Da hast sich vermutlich etwas überschnitten (siehe /edit im Beitrag #33).

[OT]
Mir hat das so immer gereicht, da ich ja auch weiss, worum es geht und ich ja nahezu überall Kommentare zwischen habe.
Ich muss gestehen, dass ich lieber Code als Kommentare lese. Da bin ich mir nämlich sicher, dass das Gelesene aktuell ist. ;)

Meine Meinung: gute Code benötigt keinen Kommentar. (Ausnahme: Kommentare im Prozedurkopf zur Schnittstellenbeschreibung)

mfg
Josef

Storch
10.07.2012, 11:51
Hallo!
Da hast sich vermutlich etwas überschnitten (siehe /edit im Beitrag #33).
Das hatte ich noch nicht gelesen.....
Es ist wieder mal sooooooooooooo einfach. Ich bin nicht im geringsten darauf gekommen, mal die Enter-Taste zu bedienen. Maus ging nicht(logisch, wie DU es erklärst), Escape hat ebenfalls nichts gebracht, da dachte ich, die Anwendung hängt, zumal beim Abschuss über den Taskmanager noch die Meldung kam: 'Anwendung reagiert nicht'.


Meine Meinung: gute Code benötigt keinen Kommentar. (Ausnahme: Kommentare im Prozedurkopf zur Schnittstellenbeschreibung)

Ich gehöre zu denen, die sich von 12 bis mittag nix merken können, da helfen mir die Kommentare, mich schneller wieder rein zu denken.
Und außerdem liest man in allen möglichen Schriften davon, das man mit Kommentare nicht sparen sollte, damit man sich eben später schneller reinfinden kann.

Wie dem auch sei, auf jeden Fall tausend Dank für die Erleuchtung. So weiss ich jetzt wenigstens, das das Verhalten der Anwendung völlig normal ist.

Josef P.
10.07.2012, 12:21
[OT]

Hallo!

Einige wenige inhaltlich aussagekräftige Kommentare werden nicht schaden.
Aber alles mögliche zu kommentieren macht meiner Ansicht nach den Code nur unübersichtlich, weil man dann den wesentlichen Inhalt nicht sieht.

Beispiel aus deinem Code:
'Nur wenn HitTest nicht Nothing ist
If Not oTreeview.HitTest(x, y) Is Nothing Then
Den Inhalt vom Kommentar kann ich auch aus dem Code lesen.

außerdem liest man in allen möglichen Schriften davon, das man mit Kommentare nicht sparen sollte
Buchtipp: Clean Code von Robert C. Martin.

mfg
Josef

Storch
10.07.2012, 19:40
[OT]

Hallo!

Einige wenige inhaltlich aussagekräftige Kommentare werden nicht schaden.
Aber alles mögliche zu kommentieren macht meiner Ansicht nach den Code nur unübersichtlich, weil man dann den wesentlichen Inhalt nicht sieht.

Beispiel aus deinem Code:
'Nur wenn HitTest nicht Nothing ist
If Not oTreeview.HitTest(x, y) Is Nothing Then
Den Inhalt vom Kommentar kann ich auch aus dem Code lesen.

Ich hab auch so bei mir gedacht, wozu schreib ich das da eigentlich hin, das ist doch aus dem Code ersichtlich. Aber hingeschrieben habe ich es trotzdem.

[OT]
Buchtipp: Clean Code von Robert C. Martin.
mfg
Josef

Danke für den Tipp. Hab einige Rezensionen gefunden. Die Anschaffung ist es wert. Aber erst nach dem nächsten Ersten.