Office-Programmierung

Hallo zusammen!

Ich bin bisher (ausschließlich) MFC-Entwickler gewesen. Nun bin ich jetzt in einer neuen (aufmännischen!) Abteilung und dort ist Programmieren für viele ein Fremdwort. Grund warum ich hier jetzt bin ist die Tatsache, dass man offenbar möchte, dass ich meine Programmier-Kenntnisse dort nun einbringe. Worum geht es: In der Abteilung wird sehr viel (fast 90%) mit Excel gearbeitet. D.h. es wird sehr viel hin und her kopiert und sehr viel unnötig von Hand gemacht. Jetzt bin ich nur unsicher, wie ich da Programmiertechnisch ran gehen sollte. Mit meinem C++ und den MFC kann ich da recht wenig anrichten. Ich bin jetzt am Überlegen, auf was ich da wechsel und was ich lerne. Wenn ich das richtig sehe, habe ich folgende Möglichkeiten:

- VBA
- VB .net mit VSTO (Visual Studio Tools für Office)
- C# mit VSTO

Aufgrund der Volumenlizenz für Office 2007 und Visual Studio 2008 hab ich also praktisch freie Wahl. Ich vermute, dass ich mich zumindest fest entscheiden muss, ob ich mit den VSTO (sei es jetzt VB .net oder C#) oder mit VBA an das Thema ran gehe. Ich denke es wird schwer beides gleichzeitig zu verwenden. Mir ist aber auch der Unterschied der herangehensweise nicht 100%ig klar. Was ich an VBA in jedem Fall gut finde ist die Tatsache, dass ich wenn es um Automatisierung geht, die "Record"-Funktion verwenden kann. Das finde ich SEHR gut! Natürlich sind die Möglichkeiten von VBA beschränkt. Wo die Grenzen liegen weiß ich zwar nicht, aber ich denke sie sind vorhanden (und die IDE in Office ist natürlich nicht mit Visual Studio vergleichbar).

Gibt es eigentlich große Ähnlichkeiten zwischen VBA und VB.net? Dann wäre es für mich an der Zeit VB zu lernen. Als C++ Programmierer wäre natürlich ein Umstieg auf C# wesentlich leichter.

Wie man sehen kann, bin ich grade echt am überlegen. Sitze hier und frage mich, wie ich sinnvoll an das Thema ran gehe. Fakt ist: Es sollen viele Aufgaben in Excel automatisiert werden, aber auch weitergehende Operationen ermöglicht werden (z.B. auslesen von anderen Dateien und verändern von Dateien).

Könnt ihr mir bei meiner Suche helfen? Bin total überfragt!

Grüße
Chrisu

volkard

mach besser nicht den fehler, zu sagen, daß du erstmal 40 bis 50 tage brauchst, um ein gutes konzept zu erarbeiten, lass dich einfach von den benutzern treiben. schön immer VBA. immer deren excel-sheets ein wenig aufmotzen. als erster oder guter office-progg0r kannste den operators so viel arbeit abnehmen, daß sie dir sogar zu weihnachten was schenken.

Hallo Chrisu,

Chrisu schrieb:

Natürlich sind die Möglichkeiten von VBA beschränkt.

Nicht unbedingt ein Argument, denn VBA ist für Office-Anwendungen optimiert. Die Zugriffe auf die Objekte sind meiner Meinung nach einfacher und besser zu überblicken.

Chrisu schrieb:

Gibt es eigentlich große Ähnlichkeiten zwischen VBA und VB.net?

Jein, VB.net ist viel komplexer, stärker objektorientiert, man muss die .net Klassen kennen etc. VBA ist wesentlich einfacher.

Chrisu schrieb:

Dann wäre es für mich an der Zeit VB zu lernen. Als C++ Programmierer wäre natürlich ein Umstieg auf C# wesentlich leichter.

Für einen erfahrenen Programmierer ist VBA ziemlich einfach. Allerdings musst Du Dich mit den Excel-Objekten beschäftigen. Aber das gilt für Beides.

Chrisu schrieb:

Wie man sehen kann, bin ich grade echt am überlegen. Sitze hier und frage mich, wie ich sinnvoll an das Thema ran gehe. Fakt ist: Es sollen viele Aufgaben in Excel automatisiert werden, aber auch weitergehende Operationen ermöglicht werden (z.B. auslesen von anderen Dateien und verändern von Dateien).

Das geht auch mit VBA. Macht natürlich nur Sinn, wenn das aus Excel heraus passieren soll.

Zusammenfassend ist zu sagen: VBA ist einfach und trotzdem mächtig, man braucht keine extra Entwicklungsumgebung und auch kein Framework.
.net ist moderner, wahrscheinlich zukunftsicherer (aber wer weiss das schon?), vielseitiger.
Da Du offensichtlich die Freiheit hast, mach das wozu Du Lust hast!
Grüße Sue

also ich muss gestehen, dass ich nach einigem Suchen letztendlich zu folgendem Schluss gekommen bin: man letztendlich mit jeder Sprache die Visual Studio kann, auch einigermaßen für Office Programmieren. D.h. letztendlich geht es eher jetzt darum, die Sprache zu wählen, die in ZUKUNFT wohl am MEISTEN für office programmierung verwendet wird. ich komme aus der MFC-Ecke. D.h. natürlich würde ich gerne excel unter mfc programmieren. fakt ist jedoch, dass ich für mfc und excel wesentlich weniger community finden werde, als für vba. nun ist aber vba auch schon eine ganze ecke alt. daher würde ich gerne jetzt den "nachfolger" von vba lernen. stellt sich nur die frage, was das sein wird. angenommen die VSTO werden es (was ich bescheuert finde, weil man visual studio dafür braucht), sollte ich an dann c# oder vb .net lernen? denn die beiden sprachen sind ja auch nochmal unterschiedlich, auch wenn sie auf .net basieren. es sind 2 verschiedene sprachen...

der nachfolger von vba mag noch nicht feststehen, aber ich frag mich ernsthaft, ob es für mich, der von vba keine ahnung hat, noch sinn macht das zu lernen.

gruß
chrisu

Doug_HH

Wenn ich mich entscheiden müsste, würde ich auf jeden Fall für C# entscheiden.
Ich komme auch aus der MFC Ecke und bin schon vor längerer Zeit auf C++/CLI umgestiegen.
In der Firma nutzen wir auch C# und der Umstieg war für mich wesentliche einfacher als zu VB .Net.
Mit VB .Net steh ich immer noch auf Kriegsfuß.

Gruß

Unix-Tom

Also für Diene Zweck kann man das garnicht sagen. Es h´kommt darauf an was du machen willst/musst. Soll weiter mit Excel hantiert werden oder soll es in ein Programm ausgelagert werden.
Excel hantieren ist es dann VBA.
Programm dann C#.

hajb

C# soll mit der Version 4.0 voll toll für Office-Programmierung und so sein. Siehe z.B. hier

dEUs

Ich habe die anderen Beiträge nur kurz überflogen, daher mag das schon gesagt worden sein:
Das Deployment ist bei VSTO ziemlich bescheiden. Auf jedem Rechner auf dem du ein VSTO-Dokument verwenden willst musst du dieses erst deployen. Es ist also nicht mit einfachem Hin und Her-Kopieren getan.
Wenn du Office 2003 unterstützen musst, dann wird es richtig eklig, das Ganze zum Laufen zu bekommen wegen der Security (Code Access Security).
Wenn du Office 2007 unterstützen musst, dann wird das Deployment etwas freundlicher, allerdings gibt es nur über einen Umweg die Möglichkeit es für alle User zu deployen.

Für Application Level Plugins mag der Aufwand gerechtfertigt sein, da man dafür sowieso einen Installer benötigt. Bei Document level Erweiterungen ist es aus meiner Sicht nciht praktikabel.
Obwohl ich die VSTO an sich ziemlich genial finde, verwende ich meistens VBA für die Office-Automatisierung, da das Deployment bei VSTO einfach die anderen Vorteile wieder kaputt macht.