Office: (Office 365) VBA: Was ist "Tabelle1"?

Hallo,
ich bin gerade dabei einen VBA-Code für meine Zwecke anzupassen. Leider funktioniert eine der Berechnungen nicht mehr und ich bin nun auf Fehlersuche.
Dabei verstehe ich (unter anderem) folgende Deklarierung nicht:

Code:

data = Tabelle1.ListObjects("Transaktionstabelle").DataBodyRange.Value

Und zwar der Punkt "Tabelle1". Auf was bezieht sich das genau?
Wenn ich ein neues Tabellenblatt erstelle, heißt dieses ja "Tabelle1" und wenn ich eine intelligente Tabelle erstelle nennt sich diese ebenfalls "Tabelle1".
Allerdings habe ich sowohl Tabellenblatt als auch (alle) Tabellen entsprechend umbenannt (Auch die Original-Beispieltabelle hatte keine "Tabelle1" mehr, lediglich eine "Eingabetabelle", die aber sicher nicht zur Berechnung hergenommen werden kann)
Daher verstehe ich gerade nicht so richtig, wo Excel hier einen Bezug herstellt und ob er diesen vielleicht Falsch herstellt.
Aktuell sind zwei Tabellen auf einer Seite. Wenn ich diese "Aufteile" funktioniert es ebenfalls komplett nicht mehr, weswegen mich hier mal interessieren würde, wofür das "Tabelle1" hier steht, damit ich ggf. auch weiß, wie ich es später umschreiben muß, damit beide Tabellen auf getrennten Blättern sein können.
Vielen Dank

 

Hallo Andreas,

Tabelle1. ... ist der Modulname deines Tabelleblattes. Sheets("Tabelle1"). ... ist der Blattname deines Tabelleblattes.

Gruß Uwe

 

Hallo Andreas,

ein Tabellenblatt hat genau genommen zwei Namen, das kannst du im Projekt Explorer gut nachvollziehen. Wenn du eine neue Datei anlegst, steht dort Tabelle1 (Tabelle1). Wenn du jetzt das Blatt umbenennst, sagen wir mail in Meine Tabelle, dann steht dort. Tabelle1 (Meine Tabelle).
Über VBA kannst du das Blatt nun so: Sheets("Meine Tabelle") oder so: Tabelle1 ansprechen. Nun ist es aber so, dass jeder Nutzer der Datei, das Blatt umtaufen kann, jetzt heißt es meinetwegen auf einmal Daten wenn du nun im Makro mit den Blattnamen (z.B. Meine Tabelle) gearbeitet hast, findet das Makro das Blatt nicht mehr, zumindest nicht, solange der Name im Makro nicht angepasst wird.
Deshalb ist es besser, mit dem Modulnamen zu arbeiten, denn der bleibt immer gleich. (Zwar kann man den auch ändern, aber das ist schwieriger, würde der normale Anwender also nicht machen (können)).

 

Danke für die Erklärung, jetzt wo ich es sehe ist auch ganz logisch. Meine "ausgelagerte" Tabelle ist jetzt Tabelle12, deswegen hat das nicht geklappt..
Erklärt jetzt zwar nicht, warum die Berechnung (noch) nicht funktioniert, aber da bin ich auch erst gerade dran. Ich hatte das in Verdacht, aber das ist nicht der Übeltäter :)

Eine andere Änderung ist, dass in der Ursprungstabelle die Werte "Menge" und "Gesamtwert" als Zahl eingegeben wird. Bei mir wird der Gesamtwert aus Menge und Einkaufspreis errechnet. Aber das macht doch für eine Berechnung mit VBA keine Probleme, oder? Wenn da eine Formel steht wird das Ergebnis als solches berechnet.
Ich habe es aber auch schon mit Zahlen versucht, da gibt es auch keine Berechnung. Sicherlich noch irgendwo ein kleiner Fehler drin.

 

Hallo Andreas,

um da helfen zu können, müsstest du schon mal zeigen, was in deinem Makro steht, oder, am besten, du lädst eine Beispieldatei hoch.

 

Das ist ein riesiges Listing und der Ersteller war "recht faul". Es gibt also keinerlei Infos darüber, wofür die Funktion da gerade ist und selbst beim deklarieren hat er selten "Dim As" sondern nur "DIM A, I$" gesetzt... Macht man wohl auch nicht mehr.
Von daher möchte ich keinen Zumuten sich da durch zu arbeiten.
Ich habe meinen Fehler gefunden. War in einem anderen Modul. Dort mußte man an ZWEI Stellen die Größe der Tabelle anpassen. Ich hatte es nur an einer Stelle gemacht.. Jetzt funktioniert es. Ich bin schon einen großen Schritt voraus. Jetzt kann ich mich daran machen die Tabellen zu "Teilen", aber dafür habe ich ja eigentlich auch schon alle Informationen.

Aber vielleicht noch eine andere Frage: Kann ich in VBA eigentlich Code temporär "abschalten"?
Ich habe hier so einige Blöcke, von denen ich annehme, dass sie von meiner Tabelle nicht benötigt werden. Bzw. habe ich auch Tabellen, wo immer wieder mal Code dazu gekommen ist und ich nicht mehr durchsteige, welcher aktuell überhaupt noch genutzt wird und welcher veraltet oder Doppelt ist (Gerade aus meiner "Anfangszeit", wo das Chaos vorherrschte).
Ich weiß natürlich, dass man mit einem Hochkomme die Zeilen einfach ignorieren kann, mache ich auch bei 6-Zeilern, aber wenn das 30 oder mehr Zeilen sind, ist das schon nerviger.. Kann man da irgendwas "ausschalten", oder sie vielleicht in ein anderes Modul verschieben und dieses "ignorieren" lassen?

 

Hallo Andreas,

das was du als faul beschreibst ist eine Kurzschreibweise und ist gängig. A wird als Variant deklariert in I$ als String.
Ganz ehrlich. Mir ist es lieber nur minimalste Kommentierungen im Code zu haben. Solche Sachen sind einfach besser zu lesen.

Oder anders ausgedrückt: Als erstes lösche ich die vielen Kommentare und Leerzeilen raus, um Zusammenhänge besser erkennen zu können.

Ansonsten, lade einfach den Kram mit einer klaren Fragestellung anonymisiert hoch.

Gruß Uwe

 

VBA kennt die "bedingte Kompilierung". Damit kannst du auch größere Bereiche "ausklammern".

Knobbi38

 

Hallo,

zusätzlich zu knobbi38 (bedingte Kompilierung) kann man auch durch normalen Visual-Basic-Code Teile von der aktuellen Ausführung herausnehmen.
Zum Beispiel:
IF False THEN
bisheriger Code, der abgeschaltet werden soll
END IF

Soll er (wieder) aktiviert werden:
IF True THEN
Code, der hinzugeschaltet werden soll
END IF

 

Im VBA Editor Rechtsklick auf die Symbolleiste --> Anpassen --> Reiter Befehle --> Kategorien "Bearbeiten" --> In der rechten Listbox "Block auskommentieren" und "....aufheben" suchen, jeweils mit gedrückter Maustaste in die Symbolleiste ziehen --> OK

Damit kannst Du künftig den markierten Code blockweise aus/kommentieren

 

Moin Andreas,
dann will ich zu diesem erfeulich konstruktiv verarbeiteten Thema mal auch noch meinen Senf dazugeben:

integer = %, long = &, single = !, double = #, string = $ sind die faulen Abkürzungen, die ich der lausigen Lesbarkeit wegen auch lange abgelehnt habe. Inzwischen nutze ich die fünf genannten allerdings ganz gerne. Denn auch wenn Intellisense beim Deklarieren eigentlich behilflich sein soll, bleibe ich zu oft anTippfehlern oder versehentlich falsch erwischten Variablentypen hängen.
Dazu kann man sich natürlich einen kleinen Spickzettel zur Übersetzung zurechtlegen. Ich kann mir die Kürzel inzwischen aber mit dieser Eselsbrücke ganz gut merken % + & liegen oberhalb der Ziffern 5 + 6 und sind integer + long, ! ist eine senkrechte, die # sind zwei, also single + double, bleibt nur $ für Text und das Wort hat 4 Buchstaben.

@knobbi38 hat vor Jahren schon mal den Tipp mit den Codenamen von Arbeitsblättern gegeben, was ich seither konsequent nutze. Neben dem Schutz gegen das Umbenennen der Arbeitsblätter durch Benutzer bringt es nämlich noch etliche Vereinfachungen im Code und in der Handhabung.
Meine Standardblätter heißen z.B. sht_data, sht_formulas oder sht_output, woran sich schon gut das EVA-Prinzip erkennen lässt. Außerdem ist mit dem Präfix sheet die von M$ bis heute gepflegte Benennungsschlamperei zum Begriff Tabelle umgegangen. Denn das, was beim Öffnen einer Arbeitsmappe erscheint, sind eben keine Tabellen, sondern Arbeitsblätter. Du hast in Deinem Projekt auch ein klassisches Beispiel: Stichwort ListObject, ein Tabellen-Objekt.
Als konkretes Beispiel für die Vereinfachung des Codes: In DieseArbeitsmappe habe ich z.B. diesen Code:

Code:

Private Sub Workbook_SheetActivate(ByVal Sht As Object)
    If Sht Is sht_Data
        Cells(1, 1).Select
    End If 
End Sub

Wollte ich das (also, dass mir der Cursor beim Aktivieren des Arbeitsblatts "Daten" in Zelle A1 flitzt) mit der allg. üblichen Syntax erreichen, bräuchte ich statt der drei If/End if-Zeilen diesen Bandwurm:

Code:

If ThisWorkbook.ActiveSheet.Name = ("Tabelle1") then ...

Die sht_Nomenklatur spart also knapp 50% Code (=Tippfehler und Umschalttasten-Akrobatik) . Das funktioniert auch schon bei einfachen With/End With-Blöcken: Statt With ThisWorkbook("Tabelle1") genügt With sht_Data.

Knobbi hat auch auf die bedingte Kompilierung hingewiesen. Ein Konzept, das für die vier möglichen Programmierumgebungen (Win 32, Win64, VBA7/Office 2010 bzw. neuer und macOS) leider auch jeweils eigene Deklarationen/Syntax braucht.
Da bevorzuge ich doch die grüne Methode. Um verschiedene Varianten einer Schleife, Prozedur oder was auch mmer auszutesten, markiere ich sie, klicke in der VBE-Menüleiste zwei, drei Mal auf Block auskommentieren und kann ihn dann bei funktionierem Code auch leicht entsorgen/reaktivieren.

Sowohl für die Variablen-Kürzel als auch für die auskommentierten Blöcke ist natürlich eine Suchen/Ersetzen-Routine in VBA machbar. So könnte man z.B. Code zur Veröffentlichng im Forum oder zur Weitergabe an andere schnell gut lesbar machen. Mal schauen, wann ich dazu kommme (bzw. falls nicht eine Kollege hier einfach schneller ist ) Gibt's dann auf den VBAsteleien.de

Wie gesagt: Senf - gute Wurscht schmeckt mit und ohne ...

Schöne Grüße

 

Moin!
Ich komme mal auf die Threaderöffnung zurück.

Bisher habe ich "eigentlich" noch keine richtige Antwort gelesen.
In VBA gibt es Objekte, Auflistungen, Eigenschaften und Methoden.
Bei Tabelle1.ListObjects() ist Tabelle1 das Objekt Tabelle1 mit der Auflistung der zugehörigen ListObjects
Dieses Objekt hat unter anderem die Eigenschaften .Name und .CodeName.
Die Bezeichnung des Objekts Tabelle1 ist identisch mit seinem CodeName.

Two Cents
Ralf

 

Das ist ja nur die halbe Miete. Mit den angegeben vordefinierten Konstanten kann man verschiedene Ausführungsumgebungen berücksichtigen. Das Konzept mit der bedingten Kompilierung gilt natürlich auch Allgemein und kann für eigene Zwecke sehr gut verwendet werden, also z.B. für das Einbinden verschiedene Sprachkonstanten oder setzen von verschiedenen Debug-Leveln usw. wie in diesem Beispiel mit der "#Const Variante = 1" :
Bedingte Kompilierung - Das VBA-Tutorial
So könnte man die Konstante auch mit "#Const Variante = 2" definieren und anschließend z.B. mit "#If Variante < 2 " bestimmte Bereiche ausklammern.

Tip:
"#Const" gilt nur für das spezifische Modul/Klasse, möchte man eine "Bedingte Konstante" global definieren, wird das in den Projekteigenschaften in der VBE hinterlegt. Mehrere Definitionen werden dabei mit dem Trennzeichen ":" getrennt!

Knobbi38

Codebeispiel:

Code:

#Const LCID = 1033

Sub Test()
 
  #If DBG > 1 Then
    Debug.Print "DBG > 1"
  #End If
 
  #If LCID = 1033 Then
    Debug.Print "English - United States"
  #Else
    Debug.Print "German - Germany"
  #End If
 
End Sub

 

Ich habe das nur so gelesen und wiedergegeben. Ich persönlich würde die lange Schreibweise bevorzugen, weil es einfach Lesbarer ist. Genau so wie die Kommentare, denn ich muß immer damit rechnen, dass ich irgendwann mal eine Änderung vornehmen muß und dann muß ich mich nicht durch den ganzen Code suchen, sondern einfach nur nach bestimmten Key
words suchen, die ich mir setze um markante Stellen wiederzufinden.

Toll, das reicht mir erstmal. Danke!

Ich glaube, wenn man VBA so richtig drauf hat, wird das unweigerlich passieren. Wenn der Code allerdings weitergegeben wird, kann das für denjenigen dann unübersichtlich werden. Bei mir war es z.B. an einer Stelle so, dass der Code-Hersteller mit einer Zeichenkette gearbeitet hat und ich mit einer Zahlenkette. Dadurch war die Variable falsch deklariert. War zwar auch nur eine Kleinigkeit und ich ahnte es schon, mußte es dann aber doch erstmal finden.

Also für mich war die zweite Antwort von Klaus-Dieter schon alles sagend. Das hat mir dann auch beim Aufteilen der Tabelle geholfen, dies hat nämlich ohne Probleme geklappt.
Mir ging es ja hierbei nur auf die "Tabelle1". Da bin ich etwas blind gewesen, weil ich immer nur auf Excel geschaut habe und nicht in die VBA-Leiste.

Ich bin jetzt tatsächlich sehr angestachelt von meinem Erfolg mit dieser Tabelle und sie nun funktioniert, dass ich mich näher mit der VBA-Programmierung beschäftigen möchte. Ich will mal schauen, ob es nicht irgendwelche Kurse gibt, die man besuchen kann, bzw. Online machen kann. Gut möglich, dass man das jetzt doch öfter braucht auf Arbeit.