VBA - Arbeitsblatt und Zeile vom Grund der Fehlermeldung

Kolja schrieb:
> Nabend,
> wie um alles in der Welt bekomme ich heraus, welche Zeile für die ach so
> aussagekräftige Fehlermeldung "400" verantwortlich ist?
> Die Exceldatei ist ein MakroMonster, besteht aus 7 Arbeitsblättern und
> bislang ungezählten Makros / Funktionen. Da blick ich nimmer durch.
> Aus verzweifeltem Anlass
> Kolja

Auf debuggen klicken, dann wird die Zeile markiert?

Hi Karl,
es wird mir in dem Fenster nur Abbrechen und Hilfe angeboten.

Vorgehensweise.

VBA-Editor starten und Makro laden.  !!!!!

Macro ausführen, (von Excel aus oder was auch immer, gilt für alle 
Software mit eingebauten VBA-Editor).

Das Makro hält an der Stelle an, wo der Fehler auftritt bzw. abgefangen 
wird.  Nun kann man mit der Maus über die Variablen fahren und deren 
Werte ablesen.

Ansonsten (falls es sicht z.b. um einen Felhermeldung eines Abgefangenen 
Fehler handelt :

Ganz einfach den Fehler mit f9 (Haltepunkt) und F8 (Einzelschritt) 
eingrenzen.

Dazu muss auch der VBA-Editor laufen.  Dann (notfalls am Anfang) mit 
f9 ein Heltepunkt setzen.

Nun das Makro starten . VBA hält an den roten Linie an. Mit F8 geht es 
dann Schritt für Schritt weiter.

Sein Problem ist, das er das Makro startet aber der VBA-Editor NICHT 
wirklich läuft. Ergo gibt es nur hässliche Fehlermeldungen.

Peter M. schrieb:
> Schlaumaier schrieb:
>> VBA-Editor starten und Makro laden.  !!!!!

Die Anleitung funktioniert einwandfrei.

Makros werden ENTWEDER in der Tabelle gespeichert ODER in der 
PERSONAL.XLS

Ergo muss man die Tabelle vorher öffnen wo das Makro ist.

Dann öffnet man den VBA-Editor. Setzt an der passenden Stelle ein 
Haltepunkt und startet das Makro von Excel aus, (VBA-Editor MUSS offen 
bleiben, sonst kein Debug-Mode)

Es hält brav an wenn es an die Stelle kommt und alles ist gut.


Du hast aber in sofern recht, das ich nicht in VBA Programmiere. Ich 
programmiere Excel fast nur über INTEROP.  Aber ich habe selbst einige 
kleine Makros in der PERSONAL.XLS drin, die mir z.b. Helfen meine 
wichtigsten Dateien schnell zu laden, Inhalte Einfügen,Hyperlinks 
entfernen,  Excel Tabellen zu kürzen (Unnötige Felder entfernen um 
Speicherplatz zu sparen) etc.

Rainer Z. schrieb:
> Mit Einzelschrittprüfung gehst Du allerdings bei großen Programmen in
> Rente, bevor Du den Fehler gefunden hast.

JA und Nein.

Man setzt Haltepunkte nach den "immer die Hälfte" Verfahren.

Einfach erklärt.

Man verteilt im Code 3-4 Haltepunkte , und drückt jedes Mal wenn er an 
einen Hält F5. Nun muss der Fehler irgendwo auftauchen. Dann überlegt 
man wo der letzte Haltepunkt war, der lief. Den lässt man stehen und 
entfernt alle anderen. Ab besagten Haltepunkt bis zu den wo der nächste 
NICHT ausgelöste Haltepunkt war, verteilt man wieder 3-4.

Nun das ganze noch einmal.

Spätestens nach der 3-4 Runde ist der Bereich den man mit Einzelschritt 
überwachen muss so klein, das man das Locker in 5 Minuten abarbeiten 
kann.

Bei Schleifen setzte ich meist ein Haltepunkt NACH der Schleife extra 
und entferne ihn sobald der Code da ausgeführt wird wieder. Das erspart 
mir die Schleife.

Dann wie gesagt. Entweder mit "überwachung" oder mit MAUS-OVER sich die 
Variablen anzeigen lassen, und schauen ob deren Wert / Typ der ist der 
sie sein sollten.

Zum Thema : OPTION EXPLICIT

Das bringt überhaupt nix. !!!!

Grund : Ist es ein geschaltet muss man JEDE Variable deklarieren.

Code der Läuft wenn OPTION EXPLICIT = ON
 DIM Nummer as integer
 Nummer = 10

Code der zwar Läuft aber dir Warungen rausgibt wenn OPTION EXPLICIT = 
OFF ist :

Nummer = 10

Ergibt "Warnung : Nummer ist nicht deklariert."

Für die Fehlersuche in einen Programm ist diese Funktion Schwachsinn.

Sie ist nur dafür da, Fehler zu vermeiden. Wenn der Code aber nie 
deklariert hat (Dim Befehl) führt OPTION EXPLICIT = ON  dazu das der 
Fehlerspeicher überläuft ansonsten zu NIX.

Fehler kann man nur auf die von mir angegebenen Möglichkeit finden. In 
den man den Wert von Variablen und das Ergebnis von If-Then Abfragen 
überprüft.

Ich schreibe sein VB-3.0 in VB ich kenne da JEDEN Trick.

Peter M. schrieb:
> Du schließt aufgrund von Syntaxähnlichkeiten von einer Compilersprache
> auf eine Interpretersprache.

Und du hast sowas von keine Ahnung das muss doch eigentlich aua machen.

VB KANN compilieren. ABER wenn ich das in der Entwicklungsumgebung 
laufen lasse ist das ein Interpreter wie zu guten alten GW-Basic Zeiten.

Und VBA kann TEIL-Compilieren.  Ich habe nämlich ein VBA Plugin gekauft, 
wo ich den Code NICHT sehe.

Aber Grundsätzlich ist VBA ein Interpreter. Das ist richtig. ABER hier 
geht es ja darum das man Zeile für Zeile abarbeiten muss um den Fehler 
zu finden.

Und NEIN, es ist eine Menge mehr als nur "Syntaxähnlich".  Es ist im 
Prinzip das selbe. Ich kann JEDEN Befehl von VBA via INTEROP in VB 
übernehmen, und Syntax-GLEICH !!!! Ausführen.

Es ist sogar die selbe Hilfe drin.

VBA ist nix anderes wie eine Abgespeckte Version von VB. Wo einfach nur 
der Compiler fehlt. ;)

Also lass den Schwachsinn mit deinen Aussagen. Ich habe schon Dutzende 
Programme in VB damit entwickelt und VERKAUFT !!!. Und die liefen alle 
über alle Versionen ohne UPGRADE.

Sascha W. schrieb:
> Das ist ein bekanntes Problem das mit zunehmendem Umfang an VBA Code
> irgendwann auftritt. Wenn man am Code gerade was geändert hat kann man
> dort ansetzen, aber manchmal tritt's auch nur auf einigen Installationen
> auf und wo anders läufts problemlos. An sonsten bleibt nur auf Verdacht
> Codeteile zu deaktivieren. Wann kommt die Meldung?
> Leider scheint VBA von MS auch nicht wirklich weiterentwickelt zu
> werden. Es wird mit neueren Versionen nicht besser.

Nicht unbedingt. Ich habe eine Arbeitsmappe mit 50 Arbeitsblättern und 
knapp 4000 Zeilen VBA Code. Wenn Excel nicht direkt zur Stelle des 
Fehlers springt, dann springt er in aller Regel an den Anfang der Sub wo 
der Fehler auftritt. Man kann dann Breakpoints setzen und den Code 
durchsteppen.
Ich meine auch das man die Entwicklertools aktivieren muß, damit das 
Debuggen richtig funktioniert. Wie das genau funktioniert müßte ich 
nachschauen, da ich das nicht im Kopf habe. Dazu müßte ich allerdings 
meinen Firmenlaptop hochfahren, was im Urlaub keine so gute Idee ist. Es 
gibt hier aber bestimmt genug Leute die es wissen, wie man die 
Entwicklertools aktiviert.

Nachtrag:
Die Idee von Schlaumeier ist schon OK und die Beschreibung auch. Damit 
man die Makros aber bearbeiten kann (so kommt man in den VBA-Editor) muß 
aber meines Wissens die Karte Entwicklertools aktiv sein.

Zeno schrieb:
> aber bearbeiten kann (so kommt man in den VBA-Editor) muß
> aber meines Wissens die Karte Entwicklertools aktiv sein.

Da kann ich nicht mitreden.

Ich habe noch Office-2003. Und da ist bei einer VOLL-Installation von 
Office unter EXTRAS-> Markos -> der VBA-Editor deutlich zu sehen.

Ich sehe nicht ein warum ich mir eine andere Version installieren soll. 
Wobei ich die neuen Versionen nicht einmal installieren würde wenn ich 
sie geschenkt bekommen würde.

Der Grund ist übrigens auch z.T. VBA.  Ich liebe die EIGENE Symbol-Reihe 
mit kleinen Icons wo ich mit einen Klick ein hinterlegtes Makro starten 
kann.

Peter M. schrieb:
> wo er
> die Haltepunkte setzt. :)

Richtig.

Aber dazu gehört Übung und Erfahrung.

Und beides hat der TO nicht, sonst würde er nicht fragen.

Schlaumaier schrieb:
> Ich habe noch Office-2003. Und da ist bei einer VOLL-Installation von
> Office unter EXTRAS-> Markos -> der VBA-Editor deutlich zu sehen.

Oh nein Gott, ist das die Version der Gesundheitsämter mit 
FAX-Schnittstelle?

Seit 2010 sieht es etwas anders aus.

Karl schrieb:
> Oh nein Gott, ist das die Version der Gesundheitsämter mit
> FAX-Schnittstelle?

Es ist die Version die das selbe kann wie Office-365. Aber MS nicht 
reicher macht. Für das was ich mit Excel mache, ist selbst die Version 
noch Perlen vor die Säue.

Davon abgesehen finde ich die Neuen "Menüs" scheiße. Und das überall wo 
die sind. Da klicke ich mich tot.

Um z.b. meine wichtigste Datei zu laden, brauche ich 1 (ein) Klick.

Warum. Weil ich ein Icon in der Symbolleiste habe, was ein Makro 
aufruft, was die Datei lädt.

Kolja L. schrieb:
> Gefunden mit Strg F8 und immer wieder zur nächsten
> Funktion.

Was die schnellere Variante von F8 (Einzelschritt) ist und klar die 
übliche Vorgehensweise beim Debuggen wenn man nicht ahnt wo es hängt.

Sehe es mal positiv.

Du hast wieder was gelernt.

Und Empirisch gewachsene Systeme sind irgendwann immer der Alptraum pur 
wenn da der Wurm drin ist. ;)

Irgendwann ist man dann mit neu machen besser dran.

Schlaumaier schrieb:
> Zeno schrieb:
>> aber bearbeiten kann (so kommt man in den VBA-Editor) muß
>> aber meines Wissens die Karte Entwicklertools aktiv sein.
>
> Da kann ich nicht mitreden. ...
Auf unseren Firmenlaptops ist halt das aktuelle Office drauf und es 
macht dann auch natürlich Sinn mit diesem zu arbeiten, weil es eben alle 
benutzen (müssen). Da fragt keiner ob es mir gefällt. Die Karte mit den 
Entwicklertools ist ist da eben per default nicht aktiv und man muß sie 
freischalten. Wenigstens haben sie das nicht blockiert, wie unter Word. 
Da komme ich an keine Makrofunktionalitäten mehr ran.

Peter M. schrieb:
> Mit Alt+F11
> solltest Du auch ohne Anzeige der Entwicklertools
Hmm ..., das könnte sein, im Kopf habe ich Tastenkürzel nicht. Bei mir 
sind die Entwicklertools halt generell frei geschaltet.

Peter M. schrieb:
> Wer einen Debugger bedienen kann, sollte
> aber auch ohne fremde Anleitung schnell auf den Trichter kommen
Ja  - sicher, aber wenn ich den TO richtig verstanden habe, kommt er ja 
gar nicht in den Debuggermode, um selbiges zu tun.
Wie gesagt ich habe nicht alle Schweinereien von Excel im Kopf. 
Offensichtlich sind Konfigurationen möglich, wo er bei Makroproblemen 
den Debugmodus nicht anbietet. Bei mir tut er dies, was aber an den 
aktiven Entwicklertools liegen könnte.
Was MS geritten hat viele Funktionen so zu verstecken das man die erst 
ewig suchen muß oder man sich erst in diversen Foren schlau machen muß, 
kann ich eh nicht nachvollziehen. Ich habe privat noch ein altes Office, 
da konnte man alles ohne Klimmzüge benutzen und da konnte auch kein 
Admin einem die Funktionen sperren.

Kolja L. schrieb:
> Der Fehler lag übrigens in einem Zellenvergleich, da sich Eingangsdaten
> geändert haben.  Gefunden mit Strg F8 und immer wieder zur nächsten
> Funktion.
In Excel spielt es eine Rolle wie man den Zellwert abfragt. Meistens 
wird das mit Cells() gemacht, was aber bei Zellen Probleme machen kann, 
wenn diese  Funktionen enthalten. Besser ist es da, wenn man an dieser 
Stelle Range().Value benutzt, dann bekommt man den Wert den man auch als 
Wert in der Zelle sieht.6

Peter M. schrieb:
> Und mit "Cells(5,4).value" gibt es dann auch den Wert.

Es gibt einen viel besser Grund, Zellen via Zahl zu bearbeiten.

Den ziehe ich sogar JEDEN Range vor (den ich übrigens nie benutze)

Ihr macht eure Makros immer auf eine FESTE Startzelle.

Wenn man Makros aber frei machen will, also von jeder Zelle aus starten 
will, ist das sehr negativ.

Ich bevorzuge deshalb anstelle des range-Befehl die for.next schleife.


for i = 1 to 10
cell(5,i).value = i
next i

In der Schleife kann ich dann mit der Zelle alles machen.

Und ich muss kein Range-String berechnen.

Einfach nur die Startzelle auslesen hier eine gute Anleitung dazu.
https://supportnet.de/fresh/2006/9/id1419526.asp

Peter M. schrieb:
> Von Code-Einrückungen hat unser Dozent noch nichts gehört,

Beschwerden bitte an die Foren-Software.

Aber das war schon immer so. Wer nix zu sagen hat, oder seine 0-Ahnung 
übertünchen will, kommt mit Banalitäten.

Und die dummen fallen drauf rein.  Die die es wirklich interessiert den 
ist das schei**egal.

Schlaumaier schrieb:
> Ihr macht eure Makros immer auf eine FESTE Startzelle.
Du bist wirklich ein Schlaumaier, Du kennst mein Projekt nicht und 
stellst dennoch solche Behauptungen auf.

Schlaumaier schrieb:
> Ich bevorzuge deshalb anstelle des range-Befehl die for.next schleife.
>
> for i = 1 to 10
> cell(5,i).value = i
> next i
Das mache ich meist genauso, weil es bei mir fast nie an einer festen 
Stelle los geht.
Im Übrigen kann man auch das Range-Objekt via for-Schleife durchlaufen, 
ist halt nur etwas aufwendiger.

Peter M. schrieb:
> auch das Cells-Objekt verfügt über das Attribut "value".
Ist mir nicht unbekannt hat aber an der einen Stelle warum auch immer 
nicht funktioniert bzw. nicht so funktioniert wie ich das wollte.

Zeno schrieb:
> Schlaumaier schrieb:
>> Ihr macht eure Makros immer auf eine FESTE Startzelle.

Die Aussage stammt daher da die Makro-Aufzeichnung das auch so macht.

Ich muss also jedesmal wenn ich ein Makro aufgezeichnet habe, es 
Editieren und die 1 Zeile (mit der Range / Select-Anweisung löschen.

Schlaumaier schrieb:
> Die Aussage stammt daher da die Makro-Aufzeichnung das auch so macht.
>
> Ich muss also jedesmal wenn ich ein Makro aufgezeichnet habe, es
> Editieren und die 1 Zeile (mit der Range / Select-Anweisung löschen.
Ich mache keine Makroaufzeichnung, zumindest nicht mit Excel, sondern 
schreibe es gleich in VBA. Demzufolge muß ich an dieser Stelle keine 
Umwandlung machen.

Ich habe auch noch mal bezüglich Range().Value und Cells() bzw. 
Cells().Value nachgeschaut. Bei Range ist Value vom Typ Variant und es 
wird das zurück gegeben was in der Zelle steht. Cell().Value hingegen 
führt eine implizite Typkonvertierung durch. Steht in einer Zelle z.B. 
1234 als String formatiert, dann liefert Cells().Value die Zahl 1234 
zurück, was nicht immer erwünscht ist, z.B. dann wenn man einen 
Stringvergleich durchführen möchte. Ich müßte dann nur Cells() nehmen. 
In dynamisch aufgebauten Tabellen kann das aber zum Problem werden, da 
ich dort oftmals nicht weis was am Ende in der Zelle steht.
Da nehme ich dann lieber das Range-Objekt, den das bietet noch viele 
zusätzliche Funktionen um den Inhalt und Eigenschsften einer Zelle 
heraus zu finden. Dafür muß ich dann eben die umständlichere 
Adressierung hinnehmen.

Ich muss zugeben, das meine VBA Makros zum größten Teil aus der 
Aufzeichnung stammen.

Ich mag VBA nicht (unter keiner Software) und benutze FAST immer VB mit 
INTEROP und der Passenden DLL.

Da fühle ich mich wohler, ehrlich gesagt. Da weiß ich immer genau was 
passiert und wieso. Und ich übertrage selbst Formeln in Excel-Tabellen 
via Interop. (Man muss nur den Zellen-Status vorher ändern).

Ich starte Excel via Interop, mache alles Fertig da  (sogar Diagramme) 
und je nach Aufgabe, kann der User dann die fertige Tabelle speichern.

Das erspart mir viel Arbeit. Diagramme selber malen ist harte Arbeit ;)

Peter M. schrieb:
> Wie Du sehen kannst, wird hier nichts zwangskonvertiert.
> Das Debug-Fenster liefert:
>
> 5
>  10
>  44459        20.09.2021
Doch wird es. Es gibt einen Unterschied zwischen dem was Du optisch zu 
Gesicht bekommst und dem was wirklich in der Zelle steht. Bewege einfach 
den Cursor auf Deie Zelle B6 und schau was er in der Bearbeitungszeile 
anzeigt - es wird die Formel sein. Schreibe in eine beliebige Zelle eine 
Zahl und formatiere sie danach als Datum. Dann schau was er Dir in der 
Bearbeitungszeile anzeigt, es wird nicht das Datum sein.
Das Rangeobjekt gibt das zurück was wirklich in der Zelle steht. Cells() 
ist eigentlich kein Objekt sondern eine Eigenschaft des Rangeobjektes 
bzw. des Worksheetobjektes (kann man hier 
https://docs.microsoft.com/de-de/office/vba/api/excel.range.cells bzw. 
hier 
https://docs.microsoft.com/de-de/office/vba/api/excel.worksheet.cells 
nachlesen - ich gehe mal davon aus das MS weis was sie da schreiben).

c-hater schrieb im Beitrag #6825018:
> D.h.: Es wird am Ende rauskommen, dass du Plins Müll produziert hast.
> Das war allerdings von vorherein klar. Der Sinn des Threads konnte also
> nur darin bestehen, dir zu zeigen, was du falsch gemacht hast. Aber dazu
> lieferst du einfach nicht genug Input.
War natürlich klar das hier so ein Taugenichts wieder aufschlagen muß, 
der dann auch gleich ordentlich austeilen muß und auch gleich 
ausfallend/beleidigend wird. Und nein ich werde hie von dem Code nichts 
posten, weil ich Dir keine Rechenschaft schuldig bin und es sich zum 
anderen um ein Firmendokument handelt, wo ich selbiges gar nicht darf. 
So wie ich es gemacht habe funktioniert es und das ist entscheident. Das 
ganze System, wo auch das Tabellenblatt mit dazu gehört, wollte so ein 
Oberschlauer wie Du einer zu sein scheinst nach bauen und alles besser 
machen, er ist nach 6 Jahren kläglich gescheitert. Die Firma vertraut 
nun bis auf Weiteres meinem Projekt, welche auch von der PTB abgenommen 
und für gut befunden wurde - so arg große Fehler habe ich ganz 
offensichtlich nicht gemacht.

René H. schrieb:
> Schlaumaier schrieb:
>> Davon abgesehen finde ich die Neuen "Menüs" scheiße.
>
> Was gefällt Dir daran nicht?

Das ich sie nicht mit meinen Icons füllen kann. Ich habe bei Besonders 
bei Excel alle wichtigsten Sachen in der Symbolleiste.  Allein das 
"Rahmen machen" geht um den Faktor 50 schneller. Dazu kommt einen eigene 
Symbolleiste mit Zugriff auf meine Mini-Makros.

z.b. "Inhalte einfügen" ist bei mir ein Makro-Icon.  Ich markiere den 
Bereich mit Formeln die verschwinden sollen, STRG-C, Icon anklicken, 
Fertig.

Und an diese Icons habe ich mich seit Jahrzehnten gewöhnt.

Mich kann man nur mit neuen Sachen überzeugen, wenn sie praktischer sind 
als alte, und ich schneller arbeiten kann. Und das ist bei den neuen 
Menüs nicht gegeben.

Die sollten eher versuchen Excel stabil zu machen, als immer nur am 
Design herum spielen, damit der dumme User glaubt es wäre eine neue 
Version.

Ich habe auf meinen Desktop eine Icon was eine Batch-Datei aufruft. Da 
steht nur ein Befehl drin. ;)

taskkill /F /IM excel.exe /T

Rate mal warum. ;)

René H. schrieb:
> Mit RibbonX kannst Du das. Musst es nur lernen.

O.K.

Kenne ich nicht.

Liegt aber daran das ich >2003 Versionen nur benutze wenn ich Freunden 
und Bekannten bei ihren Problemen helfe. Und an deren Rechnern verstelle 
ich nix.

Aber solange ich mit meiner Version das machen kann was ich will, werde 
ich das auch vermutlich nicht kennenlernen.

Wie schon gesagt. Es ist ja nicht so, das MS mir die neuen 
Office-Version schenkt als Dankeschön das sie meine Daten nutzen können 
im Wölkchen.