1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › .Net Core 5: Microsoft…

Und VBA?

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Und VBA?

    Autor: Akaruso 13.03.20 - 15:47

    VB ist jetzt auch nicht gerade meine Lieblingssprache, aber, wenn man z. B. ein halbwegs ordendliches UI für eine Access-Datenbank erstellen möchte, kommt man nicht um VBA herum.

    Weiß jemand, was dann in mittlerer und ferner Zukunft mit VBA passieren wird?

  2. Re: Und VBA?

    Autor: WalterSobchak 13.03.20 - 16:21

    Das sollte doch dank COM und IActiveScript sehr einfach auf zum Beispiel JavaScript umzustellen sein.

  3. Re: Und VBA?

    Autor: Akaruso 13.03.20 - 16:36

    Mag sein, aber meine Erfahrungen sind, dass man Programmierprojekte möglichst einfach halten sollte und möglichst wenig Komponenten verwenden sollte. Denn jede Komponte macht irgendwann mal Probleme ;-)

    Den Code innerhalb der Anwendung (VBA) zu haben, ist daher sicherlich besser.

    Mal davon abgesehen JavaScript wäre gegenüber VBA sicherlich ein Rückschritt. Das verwende ich nur bei der Webentwicklung, und dort auch nicht gerne.

  4. Re: Und VBA?

    Autor: WalterSobchak 13.03.20 - 16:40

    Der code bleibt doch in der Anwendung und kann auch weiterhin mit der alten VBA Runtime ausgeführt werden. Sind ja intern eh alles COM Objekte mit IDispatch interfaces.

    Ob JS jetzt ein Rückschritt zu VBA darstellt mag ich nicht zu debattieren. Fakt ist VBA ist tot und JS lebt. Delphi war auch nicht schlecht.

  5. Re: Und VBA?

    Autor: Akaruso 13.03.20 - 16:48

    OK, die Ausgangsfrage meinerseits war ja, was der Nachfolger sein wird bzw. ob diesbezüglich überhaupt schon Informationen gibt.

    Wenn ich z. B. in Zukunft zu einem Element eine Eventroutine schreiben möchte, in welcher Programmiersprache wird dies sein (Standard von MS)

    (Wenn dieser Standard dann JS sein wird, dann werde ich ich mich auch damit abfinden.)

  6. Re: Und VBA?

    Autor: WalterSobchak 13.03.20 - 17:31

    Das bleibt doch alles wie es ist. Der VBA code wird doch nicht aus Access entfernt.

  7. Re: Und VBA?

    Autor: Anonymer Nutzer 13.03.20 - 20:42

    VBA ist eine ganz andere Sprache als Visual Basic und im Office Umfeld stark verbreitet. Ich bezweifle ehrlich gesagt, dass VBA jemals aus Excel und Co. verschwinden wird.

  8. VBA wird schon seit 15 Jahren nicht mehr weiterentwickelt

    Autor: Das Rockt 13.03.20 - 21:09

    Und Office 365 kennt gar kein VBA im Web.

  9. Re: Und VBA?

    Autor: andy_0 14.03.20 - 12:56

    Ehrlich gesagt gibt es seit über 10 Jahren eine alternative zu VBA. Man kann mithilfe von Visual Studio ein Addin für die Office Produkte (Word, Excel, Access, ...) erstellen. Das ist entweder im jeweiligen Dokument integriert (-> vergleichbar zu den VBA Modulen) oder kann am Rechner installiert werden und ist dann für alle Dokumente nutzbar. Das Addin kann mit mindestens C# oder VB.NET erstellt werden.

    Insgesamt ist das eine deutlich bessere Lösung, schon alleine weil VBA seit Jahren nicht mehr weiterentwickelt wird, die IDE heutezutage ein schlechter Witz ist und die Sprache bzw. Office API-Ansteuerung ein haufen Bugs aufweist, die MS nicht mehr fixt.

  10. Re: Und VBA?

    Autor: Das Rockt 14.03.20 - 14:09

    > Ehrlich gesagt gibt es seit über 10 Jahren eine alternative zu VBA. Man
    > kann mithilfe von Visual Studio ein Addin für die Office Produkte (Word,
    > Excel, Access, ...) erstellen. Das ist entweder im jeweiligen Dokument
    > integriert (-> vergleichbar zu den VBA Modulen) oder kann am Rechner
    > installiert werden und ist dann für alle Dokumente nutzbar. Das Addin kann
    > mit mindestens C# oder VB.NET erstellt werden.

    Willst Du uns verarschen ?
    Das mag wohl für einen SW-Entwickler einfach sein, aber für den durchschnittlichen Nutzer der nur bissl VBA frickelt ist das zwei Skill-Ebenen zu hoch.

  11. Re: Und VBA?

    Autor: andy_0 14.03.20 - 14:35

    Das kommt auf die Erwartungshaltung drauf an. Du schraubst ja auch nicht wild an deinem Auto rum, ohne dich zu informieren, was gemacht werden soll. Die Entwicklungsumgebung aufzusetzen ist zwar umständlicher als in Word auf "Makros" zu drücken, aber mithilfe einer Youtube Anleitung in ein paar Schritten erledigt. Und den "Entwicklermodus" muss man in Word auch erst mal aktivieren können. Danach läuft es wie mit VBA Makros auch -> man muss Code schreiben.

    Ach und noch etwas. Jemand der ein "bissl VBA frickelt" kann das zwar gerne machen. Es ist jedoch kritisch, wenn solche "Lösungen" an andere (in der Firma) verteilt wird. Lieber jemand der sich drei Tage eingearbeitet hat und halbwegs versteht was er tut, als jemand der in nem halben Tag via "wie kopiere ich Zelleninhalt A nach B" in Google eingetippt hat und den Code ohne Verständnis kopiert.

  12. Re: Und VBA?

    Autor: Das Rockt 14.03.20 - 14:42

    > Das kommt auf die Erwartungshaltung drauf an. Du schraubst ja auch nicht
    > wild an deinem Auto rum, ohne dich zu informieren, was gemacht werden soll.

    Doch, das ist die Erwartungshaltung an eine Scriptsprache für ein Office. Niemand will deutlich gravierend komplexere Eweiterungen schreiben. Das ist was für richtige SW-Entwickler und nicht für Leute die das wie bei VBA mal nebenbei machen wollen.

  13. Re: Und VBA?

    Autor: andy_0 14.03.20 - 14:53

    Sorry, aber "deutlich gravierend komplexere Eweiterungen" ist deine Interpretation. Ich hab ein bisschen das Gefühl, es handelt sich um ein Beißreflex gegen neues. Auf Youtube finde ich Anleitungen, die in <20 Minuten Videolänge ein Projekt erstellen und es zum Schluss ausführen.

    Zur Komplexität:
    In beiden Fällen benötigst du eine Entwicklungsumgebung (integriert vs. extern). In beiden Fällen wird der jeweilige Code im Dokument hinterlegt. In beiden Fällen muss der Code händisch erstellt werden. In beiden Fällen muss der Nutzer wissen, was eine Klasse (aka Modul), Methode und Funktionsaufrufe sind. In beiden Fällen kann mit einem VB Derivat gearbeitet werden (VBA vs VB.NET). In beiden Fällen muss der Nutzer wissen oder sich einlesen, wie er auf die jeweiligen Inhalte des Dokuments zugreift.



    2 mal bearbeitet, zuletzt am 14.03.20 14:55 durch andy_0.

  14. Re: Und VBA?

    Autor: Das Rockt 14.03.20 - 14:56

    > Sorry, aber "deutlich gravierend komplexere Eweiterungen" ist deine
    > Interpretation.

    Nein, ist es nicht. VBA ist nun mal vergleichsweise leicht.
    So ist das nun mal i.d.R. mit Scriptsprachen, dass die gravierend leichter zu erlernen sind.

  15. Re: Und VBA?

    Autor: Andreas.Kreuz 14.03.20 - 15:46

    Das stimmt heute nicht mehr so ganz und ich halte es für einen schweren Irrglauben VBA für einfacher zu halten.
    Die VBA IDE ist mittlerweile einfach nur noch überholt. Die Codevervollständigung, sowie die ganzen Debugging-Optionen in aktuellen IDE‘s helfen deutlich besser wenn man eine Sprache/Umgebung nicht kennt. Ganz zu schweigen davon, dass die Fehlermeldungen aktueller Compiler deutlich aussagekräftiger sind als das was der alte VBA Interpreter so ausspuckt. Von den online-Ressourcen will ich gar nicht erst anfangen ;)
    Ich muss beruflich an alles mögliche mal ran, da ist im von CSharp über JS, Python, Shell und Powershell bis hin zu VBA alles mal dabei. Rundum sind sehr gute Tools und Helferlein zu haben, nur VBA ist in den 90ern stehen geblieben und mit Abstand am schwierigsten im Arbeitsablauf zu Händeln.
    VBA ist ein Relikt dem man nicht ernsthaft hinterhertrauern kann wenn man sich mal ein paar wenige Stunden mit einer aktuellen Sprache auseinandersetzt hat.
    Ps: JS & Py sind auch script sprachen und lassen sich wirklich sehr leicht erlernen.

  16. Re: Und VBA?

    Autor: Das Rockt 14.03.20 - 15:48

    > Das stimmt heute nicht mehr so ganz und ich halte es für einen schweren
    > Irrglauben VBA für einfacher zu halten.

    Du erzählst Quark.
    Du kannst nicht von deinem bestehenden Wissen abstrahieren, das dir hilft sowas wie .NET zuverstehen.

  17. Re: Und VBA?

    Autor: andy_0 14.03.20 - 16:14

    Da hast du natürlich einen Punkt. Jemand mit viel Erfahrung kann sein Wissen nicht 1:1 auf Anfänger anwenden. Das ändert aber nichts daran, dass hier gewisse Punkte mit VBA einfach zu sehr mit der rosa Brille gesehen werden.

    a) Eine Skriptsprache ist erst mal nicht leichter oder schwerer als kompilierte Sprachen. Eine Skriptsprache ist eine Skriptsprache, da sie kein Compiler hat sondern ein Interpreter. Punkt. Es gibt sehr einfach konstruierte Sprachen, für die sich ein Compiler wegen dem sehr beschränkten Aufbau/Einsatzbereich kaum lohnt (-> Batch etc.). VBS / VBA würde ich da nicht so dazu zählen.

    b) Die IDE in VBA ist furchtbar. Da hat Andreas.Kreuz vollkommen recht. Gutes Intelli Sense kann das Arbeiten, insbesondere für Anfänger, deutlich erleichtern.

    c) Du nimmst an, dass man sich mit .NET auskennen muss um die Addins für Office zu schreiben. Dem ist aber nicht so. Grundsätzlich benötigt man Kenntnisse mit der jeweiligen Anwendung (Word, Excel, ...) und deren API. Aber die benötigst du in VBA auch.

    d) VBA ist vollkommen verbuggt. Sobald man etwas mehr macht als "greife auf Zelle A zu", kommt man zu Einschränkungen oder Problemen. Diese haben Workarounds, die wieder Workarounds haben und dann teilweise wieder nen Bug womit es wieder nicht klappt. Das ist in keinster weise "anfängerfreundlich", da diese damit total übefordert sind.
    Persönliche Erfahrung: meine Abteilung hat was in VBA gebaut. Und so einiges ging nicht korrekt. Nach einiger Zeit wurde beschlossen, dass sich erfahrene Entwickler (anstatt der Praktikant) dem Thema annehmen. Die haben aber nach einigen Tagen festgestellt, dass Problem 1 (P1) zu P2 zu P3 führt und damit Teile nicht so umsetzbar waren wie gewollt. Am Schluss hat man sich entschieden, alles in C# als Addin neu zu bauen.

    e) Die Dokumentation in VBA und der Office API ist teilweise uralt, die Community kaum vorhanden. Die Entwicklung mit Addin löst das Problem zwar an einigen Stellen (nämlich die direkt sprachbezogenen Probleme), die mit der API jedoch nicht. Aber immerhin ist es etwas besser.

  18. Re: Und VBA?

    Autor: Das Rockt 14.03.20 - 16:23

    > a) Eine Skriptsprache ist erst mal nicht leichter oder schwerer als
    > kompilierte Sprachen. ...

    Doch, das ist meistens so.

  19. Re: Und VBA?

    Autor: Andreas.Kreuz 14.03.20 - 21:27

    Zu meiner CSharp Anfangszeit war das bestehende Wissen reines VB6/VBA Hobby wissen. Beruflich kam erst deutlich später. Damals ging es mit wie dir heute...alles andere erschien über-kompliziert. Hat sich später (für mich) einfach als Fehler herausgestellt und ich habe mich geärgert warum ich nicht schon früher umgestiegen bin. Aber das muss natürlich nicht für alle gelten...

  20. Re: Und VBA?

    Autor: Das Rockt 14.03.20 - 21:29

    > Zu meiner CSharp Anfangszeit war das bestehende Wissen reines VB6/VBA
    > Hobby wissen. Beruflich kam erst deutlich später. Damals ging es mit wie dir
    > heute...alles andere erschien über-kompliziert. Hat sich später (für mich)
    > einfach als Fehler herausgestellt und ich habe mich geärgert warum ich
    > nicht schon früher umgestiegen bin. Aber das muss natürlich nicht für alle
    > gelten...

    Also für mich ist das alles nicht kompliziert. Aber ich geh halt mal vom durchschnittlichen Anwendert aus.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. DEUTSCHER GOLF VERBAND e.V., Wiesbaden
  2. LGC Standards GmbH, Wesel
  3. Technische Universität Darmstadt, Darmstadt
  4. SCHOTT AG, Mainz

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. Ohne DVD für 51€ pro Jahr, mit DVD für 67€ pro Jahr, reines Digitalabo für 39,99€ pro Jahr
  2. Ohne DVD + Digitalausgaben + Werbefrei auf pcgames.de lesen + 10€ Amazon-Gutschein für 51€ pro...
  3. Heft + Digital + 15€ Amazon-Gutschein + buffed werbefrei für 75€ pro Jahr


Haben wir etwas übersehen?

E-Mail an news@golem.de