ich beabsichtige ein Kalkulationsprogramm zu schreiben, welches zumindest das Ergebnis in einem Excel-Sheet ausgeben soll. Meine Frage ist, ob es sinnvoller wäre ein Add-in für Excel zu schreiben oder ein seperates VB-Programm zu schreiben, welches halt nur das Ergebnis in Excel ausgibt ?
das hängt in erster Linie davon ab, ob du die Kalkulationsanwendung als eigenständige Anwendung oder innerhalb von Office ausführen möchtest. Ein Add-In verursacht natürlich etwas mehr Overhead. Bezüglich Speicherbedarf und Performance dürfte das in der heutigen Zeit allerdings kaum eine Rolle spielen - und so groß sind die Unterschiede auch nicht. Die meisten Entwickler verwenden bei einem eigenständigen Programm eh das Objektmodell. In diesem Fall wird im Hintergrund eine Instanz von Excel gestartet. Wenn es auf die Performance ankommt, kannst du dies allerdings optimieren, wenn du das Ergebnis direkt als Open Office Document - sprich unter Verwendung der neuen Office-Formate und der dafür extra vorhandenen Klassen - schreibst.
Ein weiterer Aspekt ist die Kompatibilität. Mit VSTO erstellst du Add-Ins für Excel 2003 oder 2007. Über das Objektmodell kannst du auch vorherige Versionen von Excel berücksichtigen.
Der Rest ist weitestgehend Geschmacksache und hängt beispielsweise davon ab, wer die Anwendung hinterher nutzt. Ich würde dir auf jeden Fall die Entwicklung einer eigenständigen DLL empfehlen. Dann kannst du im Nachhinein ohne große Codeänderungen entscheiden, ob du ein Add-In, Windows Forms, WPF oder eine andere Oberfläche einsetzt.
zur Erstellung einer DLL legst du ein Projekt vom Typ "Klassenbibliothek" in der von dir gewünschten Sprache an. Im Projektmappen-Explorer setzt du unter "Verweise" dann Referenzen auf die benötigten externen Komponenten - also beispielsweise im Register ".NET" die Komponente "Microsoft.Office.Interop.Excel". Dann kannst du ganz normal deinen Code schreiben. Einziger (sichtbarer) Unterschied zu beispielsweise einem Windows Forms-Projekt ist, dass du kein Startformular hast. Außerdem wird dein Code im bin-Ordner automatisch (!) als .dll statt als .exe kompiliert. Aus deinem Projekt mit der Oberfläche setzt du dann einen Verweis auf deine eigene DLL (Register "Durchsuchen"). Schon steht die Funktionalität deiner DLL in dem Projekt zur Verfügung und du kannst die darin enthaltenen Klassen/Methoden/etc. verwenden. Die DLL wird automatisch beim Kompilieren in das Ausgabeverzeichnis deines Projekts kopiert, sodass du diese einfach mitverteilen kannst.
Bereits geschriebenen VBA-Code kannst du nicht direkt verwenden, da sich der Aufruf von Klassen/Methoden/etc. in Visual Basic leicht unterscheidet. Du kannst den Code aber dennoch einfach mal in dein Projekt kopieren und ihn als Ausgangsbasis nutzen. Du musst dann noch kleinere Änderungen an der Syntax usw. vornehmen. Das sollte aber nicht das Problem sein.
Es ist mir nicht bekannt, dass solche umfangreicheren finanzmathematischen Funktionen in VB enthalten sind. Im Internet solltest du aber leicht Beispiele finden, die du übernehmen kannst. Alternativ kannst du auch die Excel-Funktionen verwenden und diese per Code als Berechnung in das Arbeitsblatt schreiben. Allerdings sind die Funktionen in der fertigen Excel-Datei dann für jeden sichtbar.
das hängt in erster Linie davon ab, ob du die Kalkulationsanwendung als eigenständige Anwendung oder innerhalb von Office ausführen möchtest. Ein Add-In verursacht natürlich etwas mehr Overhead. Bezüglich Speicherbedarf und Performance dürfte das in der heutigen Zeit allerdings kaum eine Rolle spielen - und so groß sind die Unterschiede auch nicht. Die meisten Entwickler verwenden bei einem eigenständigen Programm eh das Objektmodell. In diesem Fall wird im Hintergrund eine Instanz von Excel gestartet. Wenn es auf die Performance ankommt, kannst du dies allerdings optimieren, wenn du das Ergebnis direkt als Open Office Document - sprich unter Verwendung der neuen Office-Formate und der dafür extra vorhandenen Klassen - schreibst.
Ein weiterer Aspekt ist die Kompatibilität. Mit VSTO erstellst du Add-Ins für Excel 2003 oder 2007. Über das Objektmodell kannst du auch vorherige Versionen von Excel berücksichtigen.
Der Rest ist weitestgehend Geschmacksache und hängt beispielsweise davon ab, wer die Anwendung hinterher nutzt. Ich würde dir auf jeden Fall die Entwicklung einer eigenständigen DLL empfehlen. Dann kannst du im Nachhinein ohne große Codeänderungen entscheiden, ob du ein Add-In, Windows Forms, WPF oder eine andere Oberfläche einsetzt.
zur Erstellung einer DLL legst du ein Projekt vom Typ "Klassenbibliothek" in der von dir gewünschten Sprache an. Im Projektmappen-Explorer setzt du unter "Verweise" dann Referenzen auf die benötigten externen Komponenten - also beispielsweise im Register ".NET" die Komponente "Microsoft.Office.Interop.Excel". Dann kannst du ganz normal deinen Code schreiben. Einziger (sichtbarer) Unterschied zu beispielsweise einem Windows Forms-Projekt ist, dass du kein Startformular hast. Außerdem wird dein Code im bin-Ordner automatisch (!) als .dll statt als .exe kompiliert. Aus deinem Projekt mit der Oberfläche setzt du dann einen Verweis auf deine eigene DLL (Register "Durchsuchen"). Schon steht die Funktionalität deiner DLL in dem Projekt zur Verfügung und du kannst die darin enthaltenen Klassen/Methoden/etc. verwenden. Die DLL wird automatisch beim Kompilieren in das Ausgabeverzeichnis deines Projekts kopiert, sodass du diese einfach mitverteilen kannst.
Bereits geschriebenen VBA-Code kannst du nicht direkt verwenden, da sich der Aufruf von Klassen/Methoden/etc. in Visual Basic leicht unterscheidet. Du kannst den Code aber dennoch einfach mal in dein Projekt kopieren und ihn als Ausgangsbasis nutzen. Du musst dann noch kleinere Änderungen an der Syntax usw. vornehmen. Das sollte aber nicht das Problem sein.
Es ist mir nicht bekannt, dass solche umfangreicheren finanzmathematischen Funktionen in VB enthalten sind. Im Internet solltest du aber leicht Beispiele finden, die du übernehmen kannst. Alternativ kannst du auch die Excel-Funktionen verwenden und diese per Code als Berechnung in das Arbeitsblatt schreiben. Allerdings sind die Funktionen in der fertigen Excel-Datei dann für jeden sichtbar.
OK, an die Financial-Funktionen hatte ich nicht gedacht, da sich diese im Microsoft.VisualBasic-Namespace befinden und ich grundsätzlich keine sprachspezifischen Klassen einsetze. Die Financial-Funktionen sind zusammen mit einigen weiteren Funktionen in .NET aus Gründen der Kompatibilität zu VB 6 enthalten. Daher würde ich diese Funktionen schnell neu programmieren bzw. auf bestehende Beispiele zurückgreifen (gibt es im Netz ja mehr als Sand am Meer) und diese in eine eigene Funktionsbibliothek einbauen.
