(27.01.2026, 18:44)Roman-1 schrieb: Bücher sind immer gut. Habe schon überlegt ein's zu kaufen.
Ich würde es lassen. Um sich einen Überblick zu verschaffen ist ein (Lehr-)buch immer gut... wenn es denn gut geschrieben ist.
Allerdings zeigt Dir ein Buch immer nur Lösungen für Probleme die Du aktuell nicht hast. In Zeiten des Internets und KI hast Du IMHO genug Power vor Deiner Nase um alle Probleme, auf de man als Normal-Sterblicher stößt, lösen zu können.
Zitat:... dann sollte ein VBA-Tutorial ausreichend sein
Das soll dann reichen, um das Programmieren und eine Programmiersprache zu lernen? Da gibt es sicherlich ein paar Aspekte mehr, als nur ein paar VBA Anweisungen kennen zu lernen.
KI hilft auch nicht wirklich weiter, weil man ohne weitere Kenntnisse die Fehler der KI gar nicht erkennen, geschweige denn beseitigen kann. Sie kann allenfalls die Arbeit bei der Softwareerstellung erleichtern, wenn man schon weiß, wie man die Ergebnisse einzuordnen hat.
Wer eine solch Meinung vertritt, braucht sich nicht zu wundern, wenn das Niveau immer weiter sinkt.
Knobbi38
Folgende(r) 1 Nutzer sagt Danke an knobbi38 für diesen Beitrag:1 Nutzer sagt Danke an knobbi38 für diesen Beitrag 28 • Klaus-Dieter
meiner Ansicht nach kann man VBA nicht mal so eben lernen. Das ist alles mindesten noch einmal so komplex wie Excel selber. Als reiner Amateur arbeite ich mit VBA, seit das in Excel zur Verfügung steht. Habe vorher aber schon mit Basic kleine Programme zunächst für den Commodore 16, später Plus4 und danach für den Amiga geschrieben. Wobei der Amiga dann ja schon ein Quantensprung war, weil der dann kein Zeilenbasiertes Basic mehr hatte, so wie das bei den anderen Commodore-Rechnern verwendet wurde. Das heißt, als Excel dann VBA bekam, war mir das schon recht vertraut, weil es dem Basic vom Amiga doch sehr ähnlich ist. Trotz der vielen Jahre, glaube ich nicht, in der Programmierung 100% fit zu sein, eben Amateur.
Viele Grüße Klaus-Dieter Der Erfolg hat viele Väter, der Misserfolg ist ein Waisenkind Richard Cobden
(28.01.2026, 11:55)knobbi38 schrieb: Das soll dann reichen, um das Programmieren und eine Programmiersprache zu lernen?
Naja, ich sag's mal so:
Ich habe kein Buch über VBA oder Pascal oder Assembler oder C und dennoch in all diesen Sprachen schon Programme geschrieben. Und das auch schon vor Zeiten des Internets... kennt Ihr noch die guten alten Zeiten des FIDO-Net wo man via Modem sich bei seinem Boss einwählen musste? 1200 Baud, man das war noch was.
Und ich habe ebenso kein Buch über Power Query oder DAX/Datenmodell oder Excel-/Formeln... ich hab mit Sicherheit die Weisheit weder in die Wiege gelegt bekommen oder mit Löffeln gefressen, auch ich muss mir ab und an trotz meiner langen Erfahrung mal Hilfe holen.
Und da Ihr mir nun auch schon geholfen hab sehe ich diese Unterhaltung klar auf gleicher Augenhöhe, nur um das klarzustellen. Und wenn ich hier was irgendwas schreibe, dann treffe ich ja auch nicht immer den Nagel auf den Kopf.
Letzten Endes muss jeder selber schauen wie er sich welches Wissen aneignet. Mein universeller Tipp (und ich denke da stimmt Ihr mit mir überein): Der beste Weg irgendeinen Code zu verstehen ist debuggen, debuggen, debuggen, bis die F8-Taste kaputt ist.
Irgendeinen Code schreiben / kopieren und dann laufen lassen ... was wird nix. Da lernt man nix.
Ich denke, ein bischen von Hier, ein bischen von Da, .. ist eine gute Mischung.
Ein Buch finde ich auch nicht so schlecht. Zum Nachschlagen von Befehlen und ein paar grundsätzlichge Infos. Ich gehöre noch zu der Generation Blatt und Papier Am PC hab ich immer 1264 Seiten offen und find dann doch nichts.
28.01.2026, 16:23 (Dieser Beitrag wurde zuletzt bearbeitet: 28.01.2026, 16:24 von knobbi38.)
Hallo Andreas,
jeder muss sein eigenes Tempo und seine eigene Lernmethode finden. Wie bereits gesagt, halte ich das Internet dafür nur bedingt geeignet. Es ist eher etwas für Menschen, die sich bereits ein wenig auskennen, denn nur so kann man dort die Spreu vom Weizen trennen.
Die beschränkten Verhältnisse zu Fidonet-Zeiten sind ja glücklicherweise heute etwa besser geworden. Schon lange nichts mehr davon gehört ... Ich denke, viele wissen gar nicht mehr, was eigentlich ein Modem ist.
... es gab mal eine Reihe ... in 12 Tagen, wenn ich mich recht entsinne. Vielleicht waren es auch 24
Ich hab mal - spaßenshalber - gegoogelt, da bringt mit der Copilot vba in 12 tagen
Bei 24 Tagen wird's schon etwas ausführlicher vba in 24 tagen
Ich hab mich dann aber schon an andere gehalten
Hier mal ein Blick in ein "Oldie-Fach" in meinem Bücherregal
Die "dickeren" Wälzer sind allerdings inzwischen großteils entsorgt. Ich hatte da einige von M&T, aus dem Addison-Wesley-Verlag, u.a. ... Ein paar habe ich aufgehoben, manchmal braucht man ja was zum "beschweren"
Im Internet findet man m.E. aber je nach Kenntnisstand reichlich Material. Youtube bietet einiges ... Thehos wird ja oft zu Excel-Themen genannt. neuer-excel-grundkurs
29.01.2026, 11:24 (Dieser Beitrag wurde zuletzt bearbeitet: 29.01.2026, 11:30 von Gast 123.)
Hallo Kollegen
ich habe da mal eine Frage, vielleicht brauche ich noch Nachhilfe im Programmieren?? Ich habe aus reiner Neugier den Code mal getestet und stutzte über diesen Befehl: Set rng = Range("Mitgliederdaten[Name]").Find(What:=6, LookAt:=xlWhole) Zu meiner Verwunderung funktioniert er! Ich war gewohnt das Sheet immer davorzustellen!
Dann fügte ich eine neue Tabelle1 ein und gab diesen Befehl an. Der erzeugt Laufzeitfehler! Set rng = Range("Tabelle1[Name]").Find(What:=6, LookAt:=xlWhole)
Könnt ihr mir erklären warum die 1. Set Anweisung funktioniert, die 2. aber nicht??? Da ist mein Excel Latein leider am Ende. Da blicke ich nicht mehr durch. Ich habe es auch mal für den Frager auf InputBox zum suchen umgestellt.
mfg Gast 123 Nachtrag für Roman bei Namenssuche verwende ich gerne Kurzbuchstaben zum suchen: z.B. Dieter Bär = d b - in der InputBox und durchsuche mit For Next alle Nachnamen und Vornamen nach gemeinsamen Treffer. Gibt es mehrere Treffer kann man auch mehrere Treffer in der MsgBox auflisten. Das ist Clevere Excel Praxis für Fortgeschrittene.
29.01.2026, 11:31 (Dieser Beitrag wurde zuletzt bearbeitet: 29.01.2026, 11:32 von Egon12.)
Hallo Gast123,
ich habe jetzt nicht in deine Datei geschaut, aber über was du stolperst ist der Range eine Listobjektes (formatierte Tabelle). Das hat also nichts mit dem Blattnamen zu tun.
Range("NameDesListObjekts[Spaltenname]")
Den Namen des Listobjekts und den Range findest du im Namensmanager.
Gruß Uwe
Folgende(r) 1 Nutzer sagt Danke an Egon12 für diesen Beitrag:1 Nutzer sagt Danke an Egon12 für diesen Beitrag 28 • Gast 123
Hi du brauchst vor Range kein Tabellenblatt angeben, wenn die Adresse, die du verwendest, ein Name ist, der in der ganzen Mappe bekannt und in dieser auch eindeutig ist. Dies ist bei einer formatierten Tabelle der der Fall.
du brauchst vor Range ebenfalls kein Tabellenblatt angeben, wenn du du diese der Adresse hinzufügst. dh das geht: Sheets("Tabelle1").Range("A1:A10"), aber man kann es auch so schreiben: Range("Tabelle1!A1:A10")
wenn man von "Tabelle" spricht, muss man im deutschen aufpassen, ob man das Tabellenblatt oder eine formatierte Tabelle (dh ein definierter Zellbereich innerhalb eines Tabellenblatts) meint.
dein: Range("Tabelle1[Name]") wäre korrekt, wenn Tabelle1 eine formatierte Tabelle ist. Wenn mit Tabelle1 jedoch das Tabellenblatt gemeint ist, ist die Syntax falsch, dann müsste nach dem Tabellenblattnamen ein "!" folgen.
Gruß Daniel
Folgende(r) 1 Nutzer sagt Danke an slowboarder für diesen Beitrag:1 Nutzer sagt Danke an slowboarder für diesen Beitrag 28 • Gast 123
Set finden: Zahl wird gefunden Name nicht
![[-]](https://www.clever-excel-forum.de/images/collapse.png)
