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
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.
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
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?
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
Hallo Bartosz, VBA für Excel ist nicht VB.
Hallo Peter, ja, ich weiß, ich wollte das nur einmal gesagt haben. Viele Grüße Bartosz
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.
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.
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.
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.
Es ist alles gesagt - nur nicht von jedem! :)
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.
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.
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: > 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.
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.
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.
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
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. :)
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.
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.
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.
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
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
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.
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
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
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 ;)
Beitrag #6825018 wurde von einem Moderator gelöscht.
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
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.
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).
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? :)
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).
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. ;)
Schlaumaier schrieb: > Das ich sie nicht mit meinen Icons füllen kann. Mit RibbonX kannst Du das. Musst es nur lernen. 😉
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.