VB 2010 und Excel 2013

  • VB.NET

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

    Radinator schrieb:

    Dim eApp As New Microsoft.Office.Interop.Excel.Application
    With eApp
    .Open(_pfadZurXlsx)
    CType(.Worksheets(_tabellenName), Microsoft.Office.Interop.Excel.Worksheet).Select()
    .Range(_zellenBereich).Vavlue = _wert
    Ist nicht das empfohlene Verfahren.
    Damit arbeitest du mit dem Application.Range-Objekt, das an das aktive Worksheet gekettet ist.
    Um Werte aus zwei Tabellen zu lesen, müsstest du permanent das Worksheet wechseln.
    .Activate und .Select sind unheimlich ressourcenfressende Methoden, da sie die ganzen GUI-Objekte (die du gar nicht benötigst) mit nachführt.
    Besser wäre:

    VB.NET-Quellcode

    1. Dim eApp As New Excel.Application
    2. Dim wb As Excel.Workbook = eApp.Open(_pfadZurXlsx)
    3. Dim ws As Excel.Worksheet = wb.Worksheets(Tabellenname)
    4. ws.Range(_zellenBereich).Value = _wert
    Bei Option Strict On musst du natürlich noch geeignet casten.
    Ich möchte nur den Unterschied aufzeigen, nicht mit Application.Range zu arbeiten, sondern mit Worksheet.Range.
    Das macht es auch ganz einfach mehr als nur ein Worksheet anzusprechen.
    Geht natürlich auch ohne extra Objektvariable: wb.Worksheets("Tabelle1").Range("A1").Value = wb.Worksheets("Tabelle2").Range("C5").Value
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „petaod“ ()

    Echt? Das Ändern von

    VB.NET-Quellcode

    1. Dim xls_ActiveSheet As New Microsoft.Office.Interop.Excel.Worksheet
    2. 'nach
    3. Dim xls_ActiveSheet As Microsoft.Office.Interop.Excel.Worksheet
    hat die Abstürze verschwinden lassen?
    Ich hätte das selbst nicht für den entscheidenden Fehler gehalten - dummer Fehler ja, aber nicht mehr als eine resourcenfressende Sinnlosigkeit.

    Was daran falsch ist, ist, dass niemals ein Worksheet mit dem Schlüsselwort New erstellt werden kann. Ein Worksheet ist immer Teil eines Workbooks, und nur ein Workbook kann ein neues Worksheet erzeugen (oder öffnen). Ist doch logisch, oder?

    Normalerweise also - wäre die Excel-Lib sauber programmiert - sollte die Zeile gar nicht kompilieren.
    Oder aber - wenns doch kompiliert - dann wenigstens keinen weiteren Schaden anrichten.

    Stattdessen schluckts die eine Version, während die annere mit einer unsinnigen und irreführenden Fehlermeldung abstürzt.
    @ErfinderDesRades

    Moin
    Ja genau nur das NEW weggelassen und es klappt.
    Ja ist irgendwie logisch.
    Ich danke dir nochmals recht herzlich für deine Tips und Ausdauer mit mir :)

    Werde mich jetzt mal an die upload und download Sache ranwagen, mal sehen ob ich es schaffe ganze ordner zu kopieren und vom ftp runterladen kann.

    Schönes Wochenende bis dann

    ErfinderDesRades schrieb:

    Normalerweise also - wäre die Excel-Lib sauber programmiert - sollte die Zeile gar nicht kompilieren.
    Ich überlege mir gerade eine mögliche Ursache.
    Wenn der Constructor als Friend definiert ist, ist er von aussen nicht mehr aufrufbar. So weit, so gut.
    Worksheets ist aus Collection abgeleitet.
    Deren .Add-Methode muss aber imstande sein, eine neue Instanz von Worksheet anzulegen.
    Also müsste man die komplette Add-Methode (von Collection geerbt) überladen, damit Worksheets.Add dennoch ein neues Worksheet erzeugen kann.
    In Office 2003 war Worksheet aber von Sheet abgeleitet und Sheet von Collection.

    Ich könnte mir vorstellen, dass es an so einer Stelle beim großen Sprung von 2003 auf 2007 Kompatibilitätsprobleme gab und man dort etwas geflickt hat, was nicht völlig durchdacht war.
    Im Laufe der Zeit hat man das dann ausgebessert und die neue Version reagiert jetzt anders (bzw. richtig).

    Dass hier der Compiler nicht schon meckert ist wahrscheinlich der Tatsache geschuldet, dass mit dem Interop-Interface auch noch Kompatibilität zu 2003er-Arbeitsmappen gewährleistet sein muss.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --