Excel und Visual Studio "Excel 2013 und 2016 VSTO-Arbeitsmappe"

  • Excel

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von petaod.

    Excel und Visual Studio "Excel 2013 und 2016 VSTO-Arbeitsmappe"

    Hallo Liebes Forum,
    ich hoffe ich bin hier im richtigen Unterforum, da es sich ja nicht direkt um VBA handelt.

    Ich möchte gerne ein CSV Import für eine Excel Datei realisieren. Früher habe ich das per "Microsoft Visual Basic for Applications" in Excel realisiert. Da ich aber nun schon eine weile mit Visual Studio gearbeitet habe finde ich den VBA Editor unglaublich unkomfortabel und unübersichtlich. Deswegen war mein Gedanke das in Visual Studio als "Excel 2013 und 2016 VSTO-Arbeitsmappe" zu realisieren.

    1. Frage: Kann man diese Herangehensweise überhaupt vergleichen?

    Ich frage deshalb, weil ich den in Visual Studio geschriebenen Code nicht im Build In VBA Editor auftaucht.

    2. Frage: Wie Muss ich die Tabelle im Code ansprechen, damit ich Daten aus einem Array in eine Worksheet Range speichern kann?

    Was ich im Netz dazu gefunden habe scheint mir immer nur neue Tabellen zu generieren. Ich möchte aber gerne fortschreiben.

    3. Frage: Visual Studio backt mir Schlussendlich eine DLL Datei. Wie kann ich die dann in Excel einbinden, damit mein Code auch außerhalb von Visual Studio funktioniert?

    4. Frage: Kann ich den Build In VBA Editor von Excel vielleicht sogar durch Visual Studio ersetzen?

    Viele Grüße,
    Darkscale
    Wer nichts weiß ist nicht Dumm sondern unwissend!
    VB.NET Neueinsteuger... aber natürlich immer in "Option Explicit" - sonst lernt man nit!
    Wenn ich dir richtig verstehe, willst auf Excel mittels VB.Net oder C# zugreifen.

    Man kann mit Office Dateien mittels COM Interop arbeiten. Dafür muss im PC, wo du die APP nutzen wirst, Office installiert sein. Die Programmierung ist ganz ähnlich als im VBA. (Also sollte kein Problem sein).

    Man kann auch ohne Excel arbeiten mittels OpenSource libraries wie Epplus.

    Mit Visual Studio erstellst du ein Programm (Console, winforms usw.) oder du kannst auch eine DLL erstellen, die du dann z.B. in einer Excel Makro abrufst. Aber wenn nur um CSV Import geht, du kannst z.B ein kleines Consolen oder Winforms App erstellen, dem du eine Datei(pfad) gibst und dann wird eine Excel Datei generiert (wie es generiert wird, programmierst du dann in VS mittels COM Interop).

    Google mal nach Excel and VB oder Excel and C#. Da wirst genug Info kriegen. Wenn aber trotzdem nicht geht, oder ich dein Vorhaben falls verstanden habe, sag bescheid und versuche weiter zu helfen :)
    Life doesn't give you a datasheet. Sometimes the docs are wrong and you have to try it.
    Mit VSTO werden Excel-AddIns erzeugt.
    Dieses AddIn musst du auf dem Zielcomputer installieren.
    Du kannst es nicht einfach in ein Workbook integrieren.

    VBA und VSTO laufen beide im Excel-Kontext.
    Beide Methoden haben ihre Daseinsberechtigung, aber sie agieren völlig unterschiedlich.

    Nur weil dir die IDE von Excel nicht so gefällt, ist das kein Grund, die Technik auf den Kopf zu stellen.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --
    Hmm ok verstehe, habe ich mir schon fast gedacht. Schade. Wäre ja cool, wenn Visual Studio sich quasi ins Excel so hätte einklinken lassen, wie es der VBA Editor ist.

    Sagt mal gibt es zum Excel VBA Editor eigentlich eine Komfortablere alternative, die sich auch anständig intigriert? Mir ist klar, dass man z.B. mit Notepad++ VBA Code schreiben kann. Ist aber nicht groß komfortabler als der Build In VBA Editor.
    Wer nichts weiß ist nicht Dumm sondern unwissend!
    VB.NET Neueinsteuger... aber natürlich immer in "Option Explicit" - sonst lernt man nit!
    Wenn du Option Explicit verwendest und damit alle Variablen sauber mit Typ deklarierst, bietet der VBA-Editor sehr wohl Features wie AutoComplete und IntelliSense.

    Leider wird auch schlampiges Programmieren unterstützt.
    Das wird aber mit fehlendem Komfort bestraft.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    petaod schrieb:

    Mit VSTO werden Excel-AddIns erzeugt.
    Dieses AddIn musst du auf dem Zielcomputer installieren.
    Du kannst es nicht einfach in ein Workbook integrieren.

    VBA und VSTO laufen beide im Excel-Kontext.
    Beide Methoden haben ihre Daseinsberechtigung, aber sie agieren völlig unterschiedlich.

    Nur weil dir die IDE von Excel nicht so gefällt, ist das kein Grund, die Technik auf den Kopf zu stellen.


    Hi Petaod,

    wozu unterscheidet man dann zwischen VSTO-Workbook und VSTO-Add in? Habe nämlich aktuell das Probelm, dass ich über VSTO-Workbook das Ribbon eines Excel-Workbooks verändert habe und jetzt nicht in die Zieldatei integriert bekomme. Building und Test läuft problemlos ab aber letztendlich ist das veränderte Ribbon so nicht in der Datei verfügbar. Ich muss es also auch als Add-in installieren?

    Thx in advance!

    cry.baby schrieb:

    wozu unterscheidet man dann zwischen VSTO-Workbook und VSTO-Add in?
    VSTO-Workbook ist ein Template im Visual Studio um VSTO-AddIns für Excel zu erzeugen.
    Das eine ist das Werkzeug, das andere das Produkt.
    Wie Farbkasten und Bild.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    cry.baby schrieb:

    Custom UI Editior
    Ist schon ein paar Jahre her, dass ich mit Ribbons gearbeitet habe.
    Das war noch zu Zeiten von Office 2007.
    Die Technik war neu und hat mich interessiert,
    Da gab es noch (fast) keine Tools.
    Damals hatte ich die XML von Hand geschrieben und ins Workbook eingezippt.

    Meine Erfahrung mit Ribbons war, dass die User überlastet waren, unter den Hunderten Steuerelementen des Excel-Ribbon schnell die benötigten Funktionen der Anwendung zu finden.
    Deswegen lasse ich heute die Ribbons für die Excel-Elemente und verlagere die anwendungsspezifischen Funktionen ins Worksheet.
    Mit ganz herkömmmlichen Steuerelementen und Range-spezifischen Mouse-Events (Click, Doubleclick, Rightclick, Contextmenu).
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --