Hi,

danke für die Antworten. Die Struktur dieses Forums ist aber auch etwas seltsam/selten. Man sieht hier nicht den gesamten Verlauf. Oder ist das EInstellungssache?

Wie auch immer: Zurück zum Thema. In vielen Punkten gebe ich dir Recht, ralf_b.

Um VBA Programmieren zu lernen, heißt die Objekte und deren Zusammenhänge der jeweiligen Application zu kennen. Wenn du die erstmal wenigstens grundlegend drin hast, dann ist das schon die halbe Miete. Ich glaube nicht, das man VBA mittels einem Buch, das man einmal liest, plötzlich kann. Da es sehr umfangreich ist, lernt man dann nur die Dinge, die man eben gerade braucht. Learning by Doing. 

Aber einige Dinge hast du nicht richtig interpretiert. Ich lerne nicht ausschließlich aus Büchern. Der Grund für die Bücher sind eben unvollständige Informationen usw. Andere Sprachen, von C, bis Java, C#, Python usw. kann man in sehr viel schnellerer Zeit erlernen und Erfolge vorweisen, obwohl sie mächtiger sind, vor allem konsistent. Das alles scheint mir in VBA nicht gegeben zu sein. VBA ist eben sehr interessant, aber irgendwie doch auch katastrophal. Ich kann mich irren, aber es scheint mir kein zu gutes Produkt zu sein, das ggf. zu viele Artefakte aus der Vergangenheit mitschleppt.

Es hilft zwar wenn man Programmierkenntnisse hat aber aber mit meinen(spärlichen) C-Kenntnissen bin ich hier auch nicht viel weitergekommen. 

Vor allem, wie du sagst, kann man Erfahrungen aus anderen Sprachen so gut wie nicht einbringen. Das ist das, was mich irre macht und extrem viel Zeit kostet !!!

Die VBA Referenz  https://learn.microsoft.com/de-de/office/vba/api/overview/  ist eigentlich ok, man muß sie nur lesen können. Das dauert halt auch seine Zeit bis man diese Sprache spicht. 

Richtig: Die ist ok, aber auch nur ok . Für manche Themen sogar gut, zumindest über die Zeit besser geworden. Dennoch würde ich VBA nicht als umfangreich bezeichnen. Umfangreich sind Java, C# und Python! Gerade deshalb sind die (aus meiner Sicht) überschaubare Anzahl an Objekten und ihre Beziehungen nicht das Problem. Es ist die Mechanismen, die nicht zu funktionieren scheinen wie in der Literatur beschrieben und das beginnt bereits bei den einfachsten Beispielen (bspw. Objekt-Erzeugung de Built-in Klassen) und der - wie ich es wahrnehme - nicht konsistenten Syntax. Dazu habe ich die Beispiele gepostet.

Was ich mit Objekt-Erzeugung meine:

Laut Literatur sollen Objekte aller Typen einheitlich mit folgender Syntax erzeugt werden können, insbes. sowohl benutzer-definierte Klassen als auch die Built-In Klassen in Office (bspw. Paragraph).

Folgender Code funktioniert:

Sub createObj_1()
   Dim b As BenutzerdefinierteKlasse
   Set b = New BenutzerdefinierteKlasse
End Sub

Folgender Code funktioniert nicht: Und ich habe mittlerweile keine Ahnung, woran das liegen könnte. Er liefert den Kompilierzeit-Fehler: "Unzulässige Verwendung des Schlsselwordts New"

Sub createObj_1()
    Dim b As Paragraph
    Set b = New Paragraph
End Sub

Was ich mit Inonsistenz meine: Auch hier am Beispiel der Objekt-Erzeugung

Wenn man ein Objekt in einer andere Sprache explizit/manuell erzeugen kann (bspw. Java), dann erfolgt das an jeder erlaubten Stelle in gleicher Weise und im besten Fall auch syntaktisch identisch.

In Java kann ich ein Objekt auf identische Weise erzeugen

• innerhalb einer Methode
• in der Argumentliste einer Methode
• usw.

In VBA herrscht Chaos:

Folgendes funktioniert:

Sub createObj_1()
  Dim b As BenutzerdefinierteKlasse
  Set b = New BenutzerdefinierteKlasse
End Sub

Folgendes funktioniert wieder nicht:

Sub uebergebenObj(bk BenutzerdefinierteKlasse)
End Sub

Aufrufe:

uebergebenObj New BenutzerdefinierteKlasse
uebergebenObj (New BenutzerdefinierteKlasse)

Beide Aufrufe, aber auch andere Varianten funktionieren nicht.

Und wenn ich allein schon an die Unregelmäßigkeiten bzw. unterschiedliches Verhalten bei Prozeduraufrufen denke !!!

• mit/ohne call
• Aufruf von Sub vs. Function
• mit/ohne runde Klammern/Argumentliste ()
• usw.

Versteht Ihr, was ich meine?