Forum: PC-Programmierung VBA - Arbeitsblatt und Zeile vom Grund der Fehlermeldung


von Kolja (Gast)


Lesenswert?

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

von Karl (Gast)


Lesenswert?

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?

von Kolja (Gast)


Lesenswert?

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

von Sascha W. (sascha-w)


Lesenswert?

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.

Sascha

von Peter M. (r2d3)


Lesenswert?

Kolja,

pflanze Breakpoints! :)

Hast Du OPTION EXPLICIT aktiviert?
Ansonsten gibt es gerne mal unerklärliche Effekte, wenn Variablen nicht 
dimensioniert werden.

Hast Du das Excel-Dings übernommen oder selbst geschrieben?

von Bartosz B. (bartosz)


Angehängte Dateien:

Lesenswert?

Hallo Kolja,

ich weiß nicht, ob es damit zusammenhängt, aber führst du genügend 
Umwandlungen durch? Das ist einfach ein Problem, wenn man mit 
Microsoft.Office.Interop arbeitet.

Man lese dies 
https://stackoverflow.com/questions/69092827/why-do-i-have-to-convert-cells-here

Von mir zusammengefasst:
- Es schreibt jemand ein programm in VB.net und fragt, warum er ‚Cells‘ 
noch casten muss – zur Laufzeit werde doch schon ‚Range‘ angezeigt.
- der statische Typ ist Object
- zur Laufzeit ist der Typ plötzlich ‚Range‘
- Und Option Strict On fällt das auf. Das ist schonmal gut. So weiß man 
bescheid und muss Ctype() schreiben
- Wenn man Interop.Excel einbindet, ist grundsätzlich alles ‚Object‘. 
Das hängt mit der Excel-Automatisierungsschnittstelle zusammen. Die 
eingebundenen DLLs arbeiten untypisiert intern.

Überprüfe, ob du Option Strict auf On hast, damit du auf nötige 
Typumwandlungen hingewiesen wirst, und Option Infer auf Off hast, 
damit du den Typ explizit deklarieren musst (also nicht Dim Test = 123; 
sondern Dim Test As Integer = 123)

: Bearbeitet durch User
von Peter M. (r2d3)


Lesenswert?

Hallo Bartosz,

VBA für Excel ist nicht VB.

von Bartosz B. (bartosz)


Lesenswert?

Hallo Peter,
ja, ich weiß, ich wollte das nur einmal gesagt haben.
Viele Grüße
Bartosz

von Schlaumaier (Gast)


Lesenswert?

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.

von Peter M. (r2d3)


Lesenswert?

Hallo Kolja,

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

an dieser Stelle packen wir das Popcorn aus und verlassen möglichst 
unauffällig den Ort des Geschehens. :)

Aus dieser Beschreibung wird ersichtlich, dass die selbsternannte 
Geistesgröße mit Excel nicht wirklich vertraut ist.

von Schlaumaier (Gast)


Lesenswert?

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.

von Rainer Z. (netzbeschmutzer)


Lesenswert?

Die Grundidee von Schlaumaier finde ich jedenfalls richtig: Den Code im 
VBA-Editor ausführen. Meine Erfahrung ist allerdings auch, dass dort 
nicht immer die fehlerhafte Zeile angezeigt wird, beispielsweise wenn 
der Code eine fehlerhafte Funktion aufruft.

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

Meine Vorgehensweise in solchen Fällen: Im Code "Stop" (ohne die 
Gänsefüßchen) einfügen vor verdächtigen Stellen, z.B. vor 
Funktionsaufruf. Dann stoppt das Programm dort und wenn kein Fehler bis 
dorthin aufgetreten ist, setze ich das "Stop" an der nächsten 
verdächtigen Stelle. Wenn der Fehler auftritt, taste ich mich zwischen 
den Stops mit weiterem "Stop"-Befehlen heran.

von Peter M. (r2d3)


Lesenswert?

Es ist alles gesagt - nur nicht von jedem! :)

von Rainer Z. (netzbeschmutzer)


Lesenswert?

Peter M. schrieb:
> pflanze Breakpoints! :)
>
> Hast Du OPTION EXPLICIT aktiviert?
> Ansonsten gibt es gerne mal unerklärliche Effekte, wenn Variablen nicht
> dimensioniert werden.

Sorry, Peter M. hatte meinen Vorschlag schon genannt. Ich mache diese 
Breakpoints genau mit diesem "Stop"-Befehl.

Ja, OPTION EXPLICIT unbedingt zum Test desaktivieren mit 'nem 
eingefügten Hochkomma vor der Zeile. ("'"). Ohne Gänsefüßchen wieder.

von Peter M. (r2d3)


Lesenswert?

Hallo Rainer Z.,

Rainer Z. schrieb:
> Ja, OPTION EXPLICIT unbedingt zum Test desaktivieren mit 'nem
> eingefügten Hochkomma vor der Zeile. ("'"). Ohne Gänsefüßchen wieder.

Du benutzt offensichtlich auch kein VBA.

OPTION EXPLICIT
einzuschalten ist erforderlich um Fehler aufgrund fehlender 
Variablendeklarationen auszuschalten, die sich nicht offensichtlich mit 
einer Fehlermeldung präsentieren.

von Schlaumaier (Gast)


Lesenswert?

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.

von Rainer Z. (netzbeschmutzer)


Lesenswert?

Peter M. schrieb:
> OPTION EXPLICIT
> einzuschalten ist erforderlich um Fehler aufgrund fehlender
> Variablendeklarationen auszuschalten, die sich nicht offensichtlich mit
> einer Fehlermeldung präsentieren.

Hier besteht vermutlich ein Missverständnis.

OPTION EXPLICIT zwingt den Anwender, Variablen zu deklarieren. Wenn 
Variablen falsch verwendet werden, führt das zu einer Fehlermeldung.

Ohne Deklaration zeigt sich VBA erstaunlich fehlertolerant bei der 
Behandlung der Variablen. Was nicht verhindert, dass es trotzdem zur 
Fehlermeldung kommen kann, wenn man etwa eine Variable vom Typ String 
mit einer Variablen vom Typ Integer addiert.

Das Desaktivieren von OPTION EXPLICIT ist somit nur ein grober Test. 
Wenn dann keine Fehlermeldung erfolgt, sollte man bei der Deklaration 
der Variablen einen Blick werfen.

von Peter M. (r2d3)


Lesenswert?

Hallo Schlaumaier,

Schlaumaier schrieb:
> 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.

Du schließt aufgrund von Syntaxähnlichkeiten von einer Compilersprache 
auf eine Interpretersprache.

Auch dieser Beitrag ist wieder ein Ausdruck Deiner unglaublichen Hybris, 
gepaart mit dem Unvermögen zur kritischen Selbstreflexion:

https://de.wikipedia.org/wiki/Metakognition

Schon der von Dir gewählte Forenname ist der Ausdruck Deiner verzerrten 
Selbstwahrnehmung.

Wenn Unternehmen ihren Namen ändern, ist das Motiv oft der Versuch einer 
Imageverbesserung in der Hoffnung, die anderen würden die 
Unternehmenshistorie vergessen. Unternehmensumbennungen sind für mich 
fast gleichbedeutend mit einem Schuldeingeständnis.

Wer mehrfach den Benutzernamen wechselt (Alexander, Pucki, Schlaumaier) 
dem unterstelle ich ähnliche Motive.
===================================================
Meine Empfehlung basiert auf der Behebung von Fehlern an eigenen 
fehlerhaften Code, der gekennzeichnet war von Fehlverhalten, zum Teil 
OHNE Fehlermeldungen.

von Schlaumaier (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Peter M. (r2d3)


Lesenswert?

Hallo Zeno,

Zeno schrieb:
> 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.

in der Firma war in der Standard-Installation der Menüeinträg nicht zu 
sehen. Das konnte man über eine Standardeinstellung umkonfigurieren.
Ich habe hier privat kein aktuelles Office am Start. Mit Alt+F11 
solltest Du auch ohne Anzeige der Entwicklertools in die VBA-Sicht 
gelangen.

: Bearbeitet durch User
von Peter M. (r2d3)


Lesenswert?

Hallo Zeno,

Zeno schrieb:
> Die Idee von Schlaumeier ist schon OK und die Beschreibung auch. Damit

Halbierungsverfahren sind überall dort sinnvoll, wo man Code halbieren 
kann.

Bei den von Schlaumeier früher propagierten Sortierverfahren mit 
Durchschnittslaufzeit von O(n*n), also die zwei geschachtelten 
For-Schleifen geht das auch sehr gut. :)

Bei meinem Code geht das nicht. Wer einen Debugger bedienen kann, sollte 
aber auch ohne fremde Anleitung schnell auf den Trichter kommen, wo er 
die Haltepunkte setzt. :)

von Schlaumaier (Gast)


Lesenswert?

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.

von Karl (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Kolja L. (kolja82)


Lesenswert?

Schlaumaier schrieb:
> Aber dazu gehört Übung und Erfahrung.
> Und beides hat der TO nicht, sonst würde er nicht fragen.

Wohl war.
Der ganze Code ist quasi eine aneinanderReihung von aufgenommenen 
Makros.
Damals dachte ich, es wäre eine gute Idee aka schnelle Lösung, es ist 
mir in der Zwischenzeit schon mehrmals auf die Füße gefallen.

Der Fehler lag übrigens in einem Zellenvergleich, da sich Eingangsdaten 
geändert haben.  Gefunden mit Strg F8 und immer wieder zur nächsten 
Funktion.

von Schlaumaier (Gast)


Lesenswert?

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.

von Peter M. (r2d3)


Lesenswert?

Hallo Kolja L.,

Kolja L. schrieb:
> Wohl war.
> Der ganze Code ist quasi eine aneinanderReihung von aufgenommenen
> Makros.
> Damals dachte ich, es wäre eine gute Idee aka schnelle Lösung, es ist
> mir in der Zwischenzeit schon mehrmals auf die Füße gefallen.

der Makrorekorder ist meiner Meinung nach nur gut dafür, um auf die 
Schnelle die Syntax von etwas zu finden.
Für eigene Zwecke sind dann aber große Codeteile überflüssig, zum 
Beispiel die unendlich vielen Selektionen im aufgenommenen Makro-Code.

Die Makros sollte man selbst schreiben.

: Bearbeitet durch User
von Zeno (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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

von Peter M. (r2d3)


Lesenswert?

Hallo Zeno,

auch das Cells-Objekt verfügt über das Attribut "value".
Wer einzelne Zellen über das Range-Objekt adressiert "hat die Kontrolle 
über sein Leben verloren" (Karl Lagerfeld).

Denn warum sollte man Zellen über koordinatenstringbasierte Objekte wie 
Range("D5") ansteuern, wenn man sie auch mittels

Cells(5,4)

adressieren kann?

Und mit "Cells(5,4).value" gibt es dann auch den Wert.

Deinen Ratschlag kann ich inhaltlich nicht nachvollziehen.

von Schlaumaier (Gast)


Lesenswert?

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

von Peter M. (r2d3)


Lesenswert?

Schlaumaier schrieb:
> for i = 1 to 10
> cell(5,i).value = i
> next i

Willkommen in der VBA-Sesamstraße!
Von Code-Einrückungen hat unser Dozent noch nichts gehört, aber er wird 
uns gleich das berühmte "Hello World!"-Programm in VBA präsentieren. 
Wahnsinn!

: Bearbeitet durch User
von Schlaumaier (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Schlaumaier (Gast)


Lesenswert?

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 ;)

Beitrag #6825018 wurde von einem Moderator gelöscht.
von Peter M. (r2d3)


Lesenswert?

Hallo Zeno,

Zeno schrieb:
> 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

Kann ich nicht nachvollziehen, siehe Beispiel unten!

> 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.

Schreibe in B5 44459 und in B6 "=B5".
Formatiere B6 als Datum "tt.m.yyyy".
Führe folgendes Makro aus:

Sub test()
    Dim a As Variant
    Dim b As Variant
    a = Cells(5, 2).Value
    b = Cells(6, 2).Value
    Debug.Print Len(a)
    Debug.Print Len(b)
    Debug.Print a, b
End Sub

Wie Du sehen kannst, wird hier nichts zwangskonvertiert.
Das Debug-Fenster liefert:

5
 10
 44459        20.09.2021

Hinweise für Schlaumeier und solche, die ihm nacheifern:
Meine Zellzugriffe sind eindeutig und sie fangen nie mit "cells..." an.
Das Makro ist lediglich das code-minimale Beispiel für Zeno, "clean 
code" sieht noch etwas anders aus.

: Bearbeitet durch User
von Zeno (Gast)


Lesenswert?

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.

von René H. (mumpel)


Lesenswert?

Schlaumaier schrieb:
> Davon abgesehen finde ich die Neuen "Menüs" scheiße.

Was gefällt Dir daran nicht? Ich arbeite seit 2006 damit, also seit der 
Einführung. Und ich komme problemlos damit zurecht, von der Nutzung bis 
zur Programmierung (RibbonX).

von Peter M. (r2d3)


Lesenswert?

Hallo Zeno,

Zeno schrieb:
> Peter M. schrieb:
>> Wie Du sehen kannst, wird hier nichts zwangskonvertiert.
>> Das Debug-Fenster liefert:
>>
>> 5
>>  10
>>  44459        20.09.2021

in einem Punkt muss ich Dir Recht geben:
Definiert man die Variable im Makro als Variant, so wird bei 
Formatierung der Zahl als Datumsstring eine Zeichenkette geliefert!

Davon wäre ich nicht ausgegangen, denn in meiner Anschauung bleibt der 
Wert einer Variable gleich, egal wie man sie formatiert.
Deklariert man die Variable jedoch strenger
DIM b as Long
dann wird wirklich nur der Wert zurückgegeben.
mit
DIM b as String
kommt zwar eine Zahl im String-Format an, aber die Excel-Formatierung 
als Datum liefert dann einen Datumsstring und nicht die numerische Zahl 
als String.

Vielen Dank für den Hinweis, dieses Verhalten hätte ich nicht erwartet.

Benutze ich das Range-Objekt, komme ich trotzdem nicht an den 
eigentlichen Wert. Von daher muss ich Dir widersprechen!

Ich habe den Beispielscode um drei Zeilen erweitert.

Sub test()
    Dim a As Variant
    Dim b As Variant
    a = Cells(5, 2).Value
    b = Cells(6, 2).Value
    Debug.Print Len(a)
    Debug.Print Len(b)
    Debug.Print a, b
    Dim c As Variant
    c = Range("B6").Value
    Debug.Print c
End Sub

Wie soll ich nun mit dem Range-Objekt an den wahren Wert kommen? :)

von René H. (mumpel)


Lesenswert?

Kolja schrieb:
> Die Exceldatei ist ein MakroMonster, besteht aus 7 Arbeitsblättern und
> bislang ungezählten Makros / Funktionen

Weshalb so viel? Vielleicht zeigst Du uns mal die Datei, vielleicht 
lässt sich da was optimieren. Das habe ich vor vielen Jahren mal 
gemacht. Da hat es ein Anwender auch gut gemeint (9000 Schaltflächen und 
3000 Prozeduren. Nach meiner Optimierung sind 2 Userformen und 9 
Prozeduren übrig geblieben).

von Schlaumaier (Gast)


Lesenswert?

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. ;)

von René H. (mumpel)


Lesenswert?

Schlaumaier schrieb:
> Das ich sie nicht mit meinen Icons füllen kann.

Mit RibbonX kannst Du das. Musst es nur lernen. 😉

von Schlaumaier (Gast)


Lesenswert?

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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.