Diskussion:Visual Basic for Applications

Letzter Kommentar: vor 8 Jahren von 62.48.72.147 in Abschnitt Nachteile

Fehlerhafte Formulierungen

Bearbeiten

Der Satz

"Die Fehlerbehandlung kann im Falle eines Fehlers nur sehr eingeschränkt und nur innerhalb der eigenen Prozedur / Funktion springen."

ist nicht korrekt. Die Fehlerbehandlung bietet im Prinzip die Möglichkeiten anderer Sprachen auch, ist allerdings auf Grund des verwendeteten On Error - Konstrukts nur sehr umständlich verwendbar. Ich würde den Satz einfach weglassen.
(Der vorstehende Beitrag stammt von 84.185.146.220 03:14, 18. Aug. 2005 (CEST) und wurde nachträglich signiert)Beantworten

Dass VBA erst ab Word 2000 integriert war, stimmt so nicht. Für Word 97 konnte man auch schon "Makros" schreiben. Ich wills aber nicht ändern, weil ich nicht weiss, ob es bereits in früheren Versionen möglich war.
(Der vorstehende Beitrag stammt von 85.178.13.240 19:23, 21. Dez. 2005 (CET) und wurde nachträglich signiert)Beantworten

Kompilieren von VBA

Bearbeiten

Ich versuche schon seit ein paar Stunden herauszufinden, ob VBA in Maschinencode kompiliert wird, oder in eine Art Vorläufer der MSIL (MS Intermediate Language - ähnlich dem Bytecode in Java). Wäre cool, wenn hier jemand darüber bescheid weiss, vielleicht hier kurz erklären könnte, wie das nun genau aussieht. thx
(Der vorstehende Beitrag stammt von 217.162.180.138 16:06, 29. Dez. 2005 (CET) und wurde nachträglich signiert)Beantworten

Ja es wird in Maschinencode kompiliert, wie das jedoch genau abläuft kann ich dir nicht sagen
(Der vorstehende Beitrag stammt von 193.159.174.201 14:24, 17. März 2006 (CEST) und wurde nachträglich signiert)

Abkürzung VBA

Bearbeiten

Wofür steht VBA denn nun genau? Oben steht "Visual Basic for Applications", unten "Visual Beginners All-Purpose Symbolic Instruction Code for Applications". Letzteres hab ich allerdings vorher noch nie gehört. 84.129.184.49 19:05, 26. Sep 2006 (CEST)

Das dürfte ja wohl klar sein. Dies ist die volle Schreibweise. Basic steht für Beginners All-Purpose Symbolic Instruction Code ;-)
(Der vorstehende Beitrag stammt von 62.167.235.176 09:28, 2006-10-28. Okt. JJJJ (CEST) und wurde nachträglich signiert)

Und wer oder was soll das sein: "Visual Beginners"? Personen die erst jetzt sehen lernen? Oder verstehe ich da das Englisch nicht richtig? -- Hbrockmann 21:18, 26. Nov. 2009 (CET)Beantworten

Visual Beginners All-Purpose Symbolic Instruction Code for Applications ~ jetzt klar? --arilou 16:39, 11. Mär. 2011 (CET)Beantworten

Neutralität des Artikels

Bearbeiten

Der Artikel ist nicht neutral, sondern teilweise negativ formuliert (Meinungsmache). Anmerkungen dazu:

  • Sicherheit: "Statt eines a priori Sicherheitskonzeptes" -- dies ist kein Merkmal der Programmiersprache, höchstens der Integration. Ich finde das Sicherheitskonzept auch nicht toll, aber man möge doch bitte Alternativen aufzeigen. Worauf bezieht sich "statt"? Der Rest der Sicherheitswarnungen ist lächerlich. Ein Programm in anderen Programmiersprachen kann genauso viel Mist bauen. Wichtig ist, dass es keine Sandbox gibt und der VBA-Code damit im Kontext des aufrufenden Programms abläuft. Damit ist VBA genauso für Schadcode aller Art geeignet wie jedes andere Programm, das nicht in eine Sandbox eingebettet ist (bat-Datei, Skripte aller Art) und in einer ausreichend vollständigen Sprache daherkommt. Sinnvoll ist in jedem Fall ein Hinweis für Laien auf die möglichen Gefahren (Schadcode-Aktivierung durch simples Öffnen eines entsprechenden Word-Dokuments).
  • "Dies ist oftmals nicht der Fall" (in Verbreitung). Woher kommt diese Erkenntnis? Warnung vor Spaghetti-Code gerne, aber das betrifft auch andere Sprachen (C, perl,...)
  • Nachteile: "mangelhaftes Sicherheitskonzept" - sagen wir mal, es gibt da nichts groß. Wenn man es mit anderen Lösungen vergleich (konkret: MS-Office-Automatisierung) sehe ich da keinen Nachteil. "keine Unterstützung von Objektorientierung" - Übertreibung, es fehlt im Wesentlichen das Vererbungskonzept, ansonsten gibt es Klassen/Objekte/Kapselung und Interfaces (Polymorphie). "mangelnde syntaktische Konsistenz": nicht nachvollziehbar. "hohes Investitionsrisiko bei mittleren bis großen Softwareprojekten": Fakten bitte. "hoher Speicherbedarf": worauf begründet sich das? Mir ist klar, dass Variant/String sub-optimal sind, aber warum "hoch"? "fehlende Normung": Naja, es gibt ja nur einen Anbieter (was ein Nachteil ist).

Im Übrigen hat VBA/VB6 mit VB7/VB.NET nicht viel mehr als den Namen gemeinsam. MS hat versucht, die Syntax von VB.NET an VB6 anzulehnen und es gibt Konvertierungsfunktionen. Allerdings ist der Code definitiv nicht kompatibel, genausogut könnte der Code von VB6 nach C# oder in eine andere Sprache (C++) tranformiert werden. Jedenfalls ist die Verwandtschaft zwischen C# und VB.NET um Klassen enger.

Zu Vorrednern in dieser Diskussion: Das Fehlerbehandlungskonzept ist praktisch genauso mächtig wie in C++/Java (try/catch). Die Syntax ist natürlich antiquiert und in den meisten Fällen umständlicher als nötig. Exceptions müsste man auch über Nummern definieren, wodurch Kollisionen möglich würden (können Exceptions in C++ nicht auch bzgl. des Namens kollidieren?) Praktisch hat das Fehlerbehandlungskonzept in VB6/VBA sogar einige Vorteile, die try/catch nicht bieten: Sprungmöglichkeiten in die fehlerauslösende Zeile oder in die darauffolgende Zeile sowie zu beliebigen Sprungmarken. Es gibt Situationen, die mit try/catch zu unlesbarem oder überlangem Code führen.
(Der vorstehende Beitrag stammt von 84.139.95.234 17:11, 15. Dez. 2006 (CET) und wurde nachträglich signiert)Beantworten


Subjektivität des Artikels

Bearbeiten

Ich empfinde viele Abschnitte des Artikels als subjektiv. Ich würde etwa nicht von "Vorteilen" und "Nachteilen" sprechen, sondern von "Stärken" und "Schwächen", da eine Stärke sich z.B. dann als Nachteil erweisen kann, wenn sie für schädliche Zwecke missbraucht wird. Eine wesentlich Schwäche bei meinen Arbeiten mit VBA ist insbesondere die lange Rechenzeit beim Sortieren und Bearbeiten großer Datenmengen. Für derartige Zwecke erscheint mir VBA im Vergleich zu C ungeeignet zu sein.

--HoXBraX (Diskussion) 13:36, 13. Nov. 2012 (CET)Beantworten

Nachteile

Bearbeiten

Das Scrollrad im VBA-Editor funktioniert nur, wenn ein einziges Editorfenster offen ist. Sind 2 oder mehr Fenster offen, funktioniert das Scrollrad wie im Artikel erwähnt, nicht. 84.155.116.93 23:59, 30. Okt. 2007 (CET)Beantworten

--Sascha Trowitzsch, MVP Access: Das Scrollrad funktioniert seit VBA 6.5 (=Office 2007) grundsätzlich in VBA-Code-Fenstern, egal, wieviele offen sind.

--Alexander Wir haben mittlerweile Office 2003. Scrollen mit der Maus geht aber trotztdem nicht :( Egal ob ein Fenster oder mehrere offen sind. Ziemlich ätzend sowas... Das liegt wohl an den Maustreiber und der noch "alten" GUI des VBA-Editors (MS Forms 2.0 vermute ich mal). Es gibt noch andere Steuerelemente die offensichtlich uralt sind und Mausrad nicht kennen. Mit der Installation eines passenden Treibers oder einer Zusatzsoftware (KatMouse) ist das Problem behoben.

Was ist mit "Die vorhandenen Einschränkungen in VBA" gemeint?
Dass ein erfahrener Entwickler mit eingeschräkten Plattformen Probleme haben kannst, ist klar. Was aber sind Einschränkungen von VBA? --62.48.72.147 07:51, 18. Jul. 2016 (CEST)Beantworten

Neutralität/Belege

Bearbeiten

Der folgende Punkt klingt für mich eher nach Werbung als nach einer inhaltlichen Aussage:

== Sprache ==
VBA ist eine sehr leistungsfähige Skriptsprache und fast immer die erste Wahl, wenn Microsoft-Office-Anwendungen (Excel, Word, Access) programmiert :werden sollen.

Welche Eigenschaften machen VBA "sehr leistungsfähig" im Vergleich zu anderen Skriptsprachen wie etwa Perl? Was macht es zur "ersten Wahl", und wieso (nur?) "fast immer"?

Und die folgende Aussage erscheint mir doch sehr zweifelhaft, gibt es dafür Belege?

== Verbreitung ==
In industriellen Bereichen von Groß- und mittelständischen Unternehmen ist VBA das Mittel schlechthin, um schnell und effizient kleinere :IT-Lösungen zu realisieren.

Wenn in Großunternehmen kleine IT-Lösungen tatsächlich hauptsächlich als Office-Makros zusammengehackt werden, muss es dafür ja irgendwo Zahlen geben... ansonsten kann man das meiner Meinung nach so nicht stehen lassen.

Ich werde zu beiden Punkten mal nachforschen, bin aber kein VBA-Experte. Weiß einer der anderen Autoren vielleicht besser bescheid?

--Glotzfrosch 10:45, 25. Nov. 2007 (CET)Beantworten

zu Sprache: Man muss schon den ganzen Satz lesen. Hier ging es um Office-Automation und da ist es nunmal die erste Wahl.

zu Verbreitung: Auch das ist völlig korrekt. Ich selbst arbeite in einem mittelständischen Unternehmen (bis 3500 MA) und es gibt bei uns ca. 1.500 Access-Anwendungen. Eben weil es die erste Wahl für Ad-hoc Anwendungen ist.

Was ist das bitte für eine Begründung? Meine Erfahrung ist, dass VBA vor allem dann Verwendung findet, wenn es in dem Unternehmen an fundamentalem IT-KnowHow etwas happert. VBA wird verwendet weil es schnell geht und "dreckige" Tricks verzeiht - meist aber auch aus der Not heraus. 84.170.72.212 21:36, 6. Apr. 2010 (CEST)Beantworten

--M.Kielmann/VBA-Programmierer

Man kann durchaus über den Syntax des vielleicht etwas überschwenglich geratenen Beitrags streiten, aber der Inhalt ist eigentlich unstrittig, weil logisch nachvollziehbar.

1. Sprache: Die Sprache VBA wurde explizit auf die Office-Anwendungen adaptiert und passt deshalb, wie man so schön sagt, " Wie Faust auf's Auge". Wer sich über den Umfang der Befehlsmöglichkeiten Gedanken macht, dem sein ein Besuch in der VBA- Hilfe empfohlen.

2. Verbreitung: Nun wirds unabwendbar, weil jeder der eine Office-CD sein Eigen nennt, den 'Agent Provocateur' bereits im Haus hat. D.h. man muss nichts herunterladen, oder zusätzlich erwerben, es ist einfach da ( Mit einem Augenzwinkern gesagt: Man könnte sich ebenso fragen, warum VW-Radkappen so verbreitet sind).

--Sascha Trowitzsch, MVP Access "Es bestehen Überlegungen, VBA langfristig durch eine .NET-basierte Technik zu ersetzen." Nicht Überlegungen, sondern höchstens Spekulationen. Wer behaupt sowas? MSFT jedenfalls nicht. Im Gegenteil: Es wird bisher festgestellt, dass VBA auf nicht absehbare Zeit integraler Bestandteil von Office bleiben, wiewohl aber nicht weiterentwickelt werde.

Zur Verbreitung ("In industriellen Bereichen von Groß- und mittelständischen Unternehmen ist VBA das Mittel schlechthin, um schnell und effizient kleinere IT-Lösungen zu realisieren."). Das stimmt schlicht und einfach nicht. Es mag gut und gerne das Mittel schlechthin sein, um kleinere Microsoft Office-Automationen zu erstellen, was ja eigentlich klar ist. Es werden bei weitem nicht alle IT-Lösungen davon abgedeckt. VBA wird z.B. selten bis nie für Web-Lösungen angewendet (da wären wohl PHP und Perl die meistverbreiteten Sprachen), es funktioniert nicht auf Unix (das zumindest auf der Server-Seite weiter verbreitet ist als Windows), es ist nicht für systemnahe Programme brauchbar usw. Der Satz sagt auch nichts wirkliches aus; für mich klingt "das Mittel schlechthin" nach 80-100% Marktanteil (subjektiv), und das hat VBA ganz sicher nicht. Und was sind "kleinere" Lösungen? Ich würde den Satz einfach löschen, überlasse das aber denen, die diesen Artikel regelmässig editieren. --Aaron Isotton/Software-Ingenieur

Solche Aussagen kommen von Anwendern, die in nicht IT-Abteilungen arbeiten. Für sie ist VBA am weitesten verbreitet, weil sie nichts anderes kennen. Betrachtet man das Ganze mal von einer neutraleren Seite: Der Anteil der Aufträge für Freiberufler im Bereich VBA liegt seit Jahren konstant unter 1 % - etwas zu wenig für "das Mittel schlechthin" finde ich. Ich verdiene unter anderem mein Geld damit die mit "den Mitteln schlechhin" realisierten Katastrophen auszumustern und durch anständige Lösungen zu ersetzen. 84.170.72.212 21:43, 6. Apr. 2010 (CEST)Beantworten
Die Stärke (ja!) liegt in dem Begriff for Application. Ohne die Hauptprogramme Excel usw. ist ein Vergleich nicht fair.-- Kölscher Pitter 04:55, 7. Apr. 2010 (CEST)Beantworten

Neutralitätsbaustein

Bearbeiten

Ich habe mal einiges überarbeitet und würde nun gerne den Neutralitätsbaustein entfernen. Gegenstimmen? --Heinzi.at 17:58, 15. Jan. 2008 (CET)Beantworten

Verbreitung

Bearbeiten

Nach einiger Zeit entstehen in der Praxis deshalb häufig Systeme, die schlicht nicht mehr weiterentwickelt werden können, da ihre Struktur kaum durchschaubar ist. ??? Was hat das mit "Verbreitung" zu tun? Ein Sch....programm zu erstellen, gelingt mit jeder Sprache. Und wenn die Sprache "kostenlos" vorhanden ist, dann wird sie auch angewendet. Von jedem, der sich traut.-- Kölscher Pitter 16:05, 27. Aug. 2009 (CEST)Beantworten

Erledigt ist ein Nachteil ;) (nicht signierter Beitrag von 2.200.202.147 (Diskussion) 07:10, 5. Dez. 2011 (CET)) Beantworten

Das ist kein Nachteil und hat nix mit Verbreitung zu tun. Klingt eher, als wolle jemand einfach VBA schlechtreden. Mit VBA kann man bei guter Vorplanung genauso gut strukturierte Anwendungen programmieren, wie mit jeder anderen Programmiersprache auch. Das Gegenteil natürlich auch, aber auch das gelingt mit jeder Programmiersprache. Da wikipedia neutral sein sollte, würde ich einen solch wertenden Satz einfach weg lassen. --84.165.157.151 19:37, 8. Apr. 2012 (CEST)Beantworten

Hab' mal "Verbreitung" aufgespaltet, jetzt gibt's auch ein Kapitel "Vorteile". --arilou (Diskussion) 12:11, 10. Apr. 2012 (CEST)Beantworten

Einleitung (imo, teilweise) verschlimmbessert

Bearbeiten

Bzgl. dieser Änderungen der Einleitung durch Benutzer:Rainald62:

Afaik kann ein VBA-Programm durchaus auch eigenständig arbeiten, und ist nicht auf die "Steuerung von Abläufen der Microsoft-Office-Programmfamilie" beschränkt. Dafür wurde die Sprache entworfen, und dafür wird sie hauptsächlich verwendet, aber (afaik) ist sie heute nicht mehr darauf beschränkt.

Aber da das "afaik" ist, und ich in VBA seit einigen Jahren nimmer ganz so firm bin, hier erst mal als Disku-Punkt (statt (Teil-)Revert).

--arilou (Diskussion) 13:30, 10. Jan. 2014 (CET)Beantworten

"Dafür wurde die Sprache entworfen, und dafür wird sie hauptsächlich verwendet", ist hinreichend, dies im ersten Satz der Einleitung mitzuteilen (das "für" hat dort, wie üblich, keine einschränkende Bedeutung, falls Du das hineingelesen hast).
Ansonsten weiß ich nicht, was dir fehlt:
  • Meinst Du mit "eigenständig arbeiten", dass VBA-Code läuft, ohne dass eines der Office-Programme läuft, also mit einem alternativen Interpreter? Du meinst nicht etwa VBScript unter dem Windows Scripting Host? Oder gar VB.Net?
  • Meinst Du mit "nicht auf die 'Steuerung von Abläufen der Microsoft-Office-Programmfamilie' beschränkt", dass Dateien bearbeitet werden können, die mit MS-Office nichts zu tun haben, z.B. plain text, und dass Formulare mit GUI-Elementen gestaltet werden können, die mit dem eigentlichen Zweck der laufenden Office-Anwendung nichts zu tun haben? Klar kannst Du mit Excel-VBA PacMan programmieren, ohne Excel-Zellen zu bemühen. Ist das relevant für die Einleitung?
Gruß --Rainald62 (Diskussion) 01:26, 11. Jan. 2014 (CET)Beantworten

// alte Version (vor dem Edit) //

Visual Basic for Applications (VBA) ist eine zu den Microsoft-Office-Programmen gehörende Skriptsprache. Sie wurde aus dem von Microsoft entwickelten BASIC-Dialekt Visual Basic (VB) abgeleitet und wurde zur Steuerung von Abläufen innerhalb der Microsoft-Office-Programme entwickelt.

// neue Version //

Visual Basic for Applications (VBA) ist eine Skriptsprache für die Steuerung von Abläufen der Microsoft-Office-Programmfamilie. Sie wurde aus dem von Microsoft entwickelten BASIC-Dialekt Visual Basic (VB) abgeleitet [...]


1) Die alte Version deutet mit "gehörend" an, dass VBA mitgeliefert wird, "integriert ist". Das ist in der neuen Version nicht mehr ersichtlich.

2) Die neue Version deutet an, dass VBA [nur] für die Steuerung von Abläufen der Microsoft-Office-Programmfamilie da ist. Die alte Version sagt, dass sie "dafür entwickelt wurde", lässt aber offen, ob sie

- inzwischen evtl. auch anderes kann;

- ob inzwischen evtl. auch weitere Einsatzfelder angestrebt werden.

Ob das "für" eine einschränkende Bedeutung hat ~ du sagst nein, ich empfinde 'ja'.

3) Ob VBA-Programme eigenständig laufen können, weis ich nicht genau. Soweit ich mich erinnere, kann man ein VBA-Makro zu einer .exe kompilieren, die zusätzlich ein Runtime Environment benötigt (einige .dll's), aber es muss kein Word/Excel/Access/PowerPoint installiert sein. Aber hier geht mein Wissen ins schwammige 'afaik' über, muss ich zugeben.

4) "Ist das relevant für die Einleitung?" - als Gesamtfazit denke ich: Die alte Version der ersten beiden Sätze war besser. Die neue Version verkürzt die Aussagen, und lässt dabei Andeutungen und Möglichkeiten weg, die nicht unerheblich sind ~ und führt dafür ein 'für' ein, dass missverständlich als 'nur für' empfunden werden kann.

--arilou (Diskussion) 18:03, 11. Jan. 2014 (CET)Beantworten