Diskussion:Visual Basic for Applications

message: 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)
thread_title:  Fehlerhafte Formulierungen 

message: 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)
thread_title:  Kompilieren von VBA 

message: 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)
replies: text: Visual Beginners All-Purpose Symbolic Instruction Code for Applications ~ jetzt klar? --arilou 16:39, 11. Mär. 2011 (CET)
thread_title:  Abkürzung VBA 

message: 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)
thread_title:  Neutralität des Artikels 

message: 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)
thread_title:  Subjektivität des Artikels 

message: 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)
thread_title:  Nachteile 

message: 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)
replies: text: 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)

text: 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)
replies: text: 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)
thread_title:  Neutralität/Belege 

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

message: 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)
replies: text: Erledigt ist ein Nachteil ;) (nicht signierter Beitrag von 2.200.202.147 (Diskussion) 07:10, 5. Dez. 2011 (CET)

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