Microsoft.Office.Interop.Excel-Verweis unwirksam

  • VB.NET
  • .NET 7–8

Es gibt 59 Antworten in diesem Thema. Der letzte Beitrag () ist von Haudruferzappeltnoch.

    So sieht es jetzt aus (immer noch das Anmeckern, kein Member zu sein....) :|
    Wahrscheinlich sehe ich den Wald vor lauter Bäumen nicht, oder ?
    Bilder

    • ScreenshotTransferNachExcelF.jpg

      245,49 kB, 1.920×1.080, 77 mal angesehen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „woofy49“ ()

    Warum benötigst Du den Range sprich doch die Zellen auf dem Worksheet direkt an. (Analog zu der Zeile mit der Range Zuweisung.)
    Ansonsten schau mal in die Dokumentation learn.microsoft.com/de-de/office/vba/api/excel.range(object). Denke hierbei daran, das ist VBA bzw. VB 6.0, dass muss man immer noch ein bisschen an VB .Net anpassen.
    NB. Es ist doch schön, wenn man lesbare Namen vergibt. Siehe auch [VB.NET] Beispiele für guten und schlechten Code (Stil).

    Das wird jetzt langsam aber ein wenig trollend. Rng ist vom Typ Range und ist in dem Code identisch zu Cells(1, 1) definiert worden. Wieso verwendest Du daher rng.Cells(1, 1).Value? Das ist das gleiche wie Cells(1, 1).Cells(1, 1).Value. Das ergibt keinen Sinn. rng.Value = WasAuchImmer ist richtig.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    hier ein Bsp. mit range

    VB.NET-Quellcode

    1. Private Sub Button49_Click(sender As System.Object, e As System.EventArgs) Handles Button49.Click
    2. Dim Path As String = "E:\" 'Pfad
    3. Dim strFilename As String = "E:\TestFolder\aa50235.xlsx"
    4. Dim myExcel As New Microsoft.Office.Interop.Excel.Application()
    5. Dim WorkBook As Workbook = myExcel.Workbooks.Add
    7. Dim WorkSheet1 As Excel.Worksheet = CType(WorkBook.Sheets.Add(), Excel.Worksheet)
    9. With WorkSheet1
    10. .Name = "Einkauf"
    11. .Range("A1").Value = "Header 1"
    12. .Range("B1").Value = "Header 2"
    13. .Range("C1").Value = "Nr."
    14. .Range("A2").Value = "abc"
    15. .Range("B2").Value = "def"
    16. .Range("C2").Value = 12354
    17. 'etc
    18. '....
    19. '...
    21. End With
    23. Dim vRes As DialogResult = DialogResult.Yes
    24. If System.IO.File.Exists(IO.Path.Combine(Path, strFilename)) Then
    25. vRes = MessageBox.Show(String.Format("the ExcelFile :'{0}' exsits, do you want to replace it?", strFilename), _
    26. "Microsoft Excel", MessageBoxButtons.YesNoCancel, MessageBoxIcon.Exclamation, MessageBoxDefaultButton.Button2)
    27. myExcel.DisplayAlerts = False
    28. End If
    29. If vRes = DialogResult.Yes Then
    30. WorkBook.SaveAs(strFilename)
    31. End If
    32. WorkBook.Close()
    33. myExcel.Quit()
    34. End Sub

    Vielen Dank, Kasi, für Dein Beispiel!
    Leider kommt es zu derselben Kritik: Auf der Ebene des Arbeitsblattes werden offenbar die Eigenschafts-Beschreibungen von "Worksheet" nicht
    mitgenommen:
    Bilder

    • ScreenshotTransferNachGxcelH.jpg

      119,16 kB, 1.920×1.080, 59 mal angesehen

    Was ist das denn in Post#24?
    Die Value-Property von Range soll vom Typ String sein? Das stimmt aber nicht. Dann ist da ein Verweis falsch. Das muss vom Typ Object sein. Das ist nicht der richtige Range-Datentyp. Wahrscheinlich zu viele importierte Namespaces und jetzt weiß der Compiler nicht, welchen er für Range hernehmen sollm und nimmt prompt den falschen, aus irgendeiner anderen DLL.
    Was sagt der Compiler zu dem Projekt im Anhang?
    Dateien

    • WinFormsNetVB.zip

      (458,28 kB, 149 mal heruntergeladen, zuletzt: )
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Ich verstehe es einfach nicht 1
    Der unveränderte Code (Vapori...), der als eigenes Programm funktioniert, wird - eingebaut in mein bisheriges, welches ich von
    Import-Anweisungen u. a. befreit habe - hier angemeckert: .visible, .range etc. seien alles keine Member. Warum übernimmt er hier nicht
    von office.interop.excel die Eigenschaften bzw. Methoden ?( ?( ?(

    Dabei ist im Projektmappen-Explorer doch alles vorhanden und aufgeführt (siehe zweites Bild)
    Bilder

    • ScreenshotTransferNachGxcelK.jpg

      337,25 kB, 1.920×1.080, 58 mal angesehen

    • ScreenshotTransferNachGxcelM.jpg

      380,22 kB, 1.920×1.080, 58 mal angesehen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „woofy49“ ()

    Schreibst Du etwa Deinen eigenen OfficeWrapper?!? :cursing:
    Was Du da hast, ist eine selbsterstellte Klasse! Da können wir uns ja hier dumm und dusselig schreiben. Kein Wunder, dass hier nix funktioniert. Schmeiß das weg, wenn Du ein laufendes Programm haben willst, damit der Compiler sauber auf die offizielle Excelbibliothek zugreifen kann.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Zu VaporiZed: Schreibst Du etwa Deinen eigenen OfficeWrapper?!? :cursing:
    Was Du da hast, ist eine selbsterstellte Klasse!

    Nein: Ich habe nichts selbst geschrieben (hätte gar keine Ahnung davon....), habe nur (rechts Bild) im Projekt-Mappen-Explorer
    die Verweise aufgeklappt, um zu belegen, dass das System mit dem MS.Interop.Office-Paket verbunden ist - mehr nicht.

    Offenbar liegt das Problem aber auf einer ganz anderen Ebene. Ich habe versucht, Deinen Beispiel-Code an meine
    Idee anzupassen und ihm das typisierte Dataset zugefügt. Und prompt ergibt sich wieder die Problematik, derentwegen ich
    überhaupt die Idee mit dem Excel-Transfer bekam. Jene Problematik hat Euch ja schon vor Kurzem erreicht, offenbar hat
    aber auch K. Löffelmann bisher keine zündende Idee gehabt, jedenfalls ist die Namensverdoppelung im Designer noch
    immer da und unterbricht das Programm (siehe Thread "absurdes Verhalten....").
    Ich bin also nach wie vor etwas ratlos.

    Aber Dein Bild ScreenshotTransferNachGxcelM.jpg zeigt eine eigene Klasse, zu der Du navigierst. Da sind Methoden drin, die leer sind (Throw New NotImplementedException). Das sind definitiv keine offiziellen Office-Methoden.
    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „VaporiZed“, mal wieder aus Grammatikgründen.

    Aufgrund spontaner Selbsteintrübung sind all meine Glaskugeln beim Hersteller. Lasst mich daher bitte nicht den Spekulatiusbackmodus wechseln.

    Nimm doch das Projekt das Vapo in Post 27 drin hat, da ist der Verweis schon eingebunden. Dann kannste auch unter "Abhängigkeiten Rechtsklick -> COM-Verweis hinzufügen" fürs nächste Mal nachgucken, wo du den Haken setzen musst.

    woofy49 schrieb:

    und ihm das typisierte Dataset zugefügt. Und prompt ergibt sich wieder die Problematik, derentwegen ichüberhaupt die Idee mit dem Excel-Transfer bekam. Jene Problematik hat Euch ja schon vor Kurzem erreicht, offenbar hataber auch K. Löffelmann bisher keine zündende Idee gehabt, jedenfalls ist die Namensverdoppelung im Designer nochimmer da und unterbricht das Programm (siehe Thread "absurdes Verhalten....")
    Äh wat? Das hat loeffel sehr wohl gelöst.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Haudruferzappeltnoch“ ()

    VaporiZed schrieb:

    Aber Dein Bild ScreenshotTransferNachGxcelM.jpg zeigt eine eigene Klasse, zu der Du navigierst. Da sind Methoden drin, die leer sind (Throw New NotImplementedException). Das sind definitiv keine offiziellen Office-Methoden.


    Dieser Verweis wurde als Fehler-Korrektur von VS generiert, als eigenartigerweise eine simple Message-Box nicht mehr angenommen wurde und
    ich diese vom System angebotene Lösung angeklickt hatte.

    Haudruferzappeltnoch schrieb:

    Nimm doch das Projekt das Vapo in Post 27 drin hat, da ist der Verweis schon eingebunden.

    Die Screenshots basieren ja auf Vapos Post Nr. 27. Der lief auch "im Original" reibungslos und schuf die Excel-Tabelle mitsamt den Beispiel-Einträgen.
    In dem Moment aber, in welchem ich ein Dataset zufügte. kam erneut diese unerklärliche Verdoppelung im MainForm-Designer, so dass ich
    wiederkehrend erst diese Verdoppelung löschen muss, bevor irgendetwas bearbeitet werden kann :
    DataSet1BindingSource.DataSource = GetType(WinFormsNetVB.WinFormsNetVB.DataSet1)
    (siehe Screenshot).
    Bilder

    • Verdoppelung.jpg

      387,94 kB, 1.920×1.080, 62 mal angesehen

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „VaporiZed“ ()

    Dann nutze was loeffel vorgeschlagen hat, Dataset im Solutionexplorer auswählen und bei den Eigenschaften in "Namespace des benutzerdefinierten Tools" den korrekten Namespace eintragen Global. DeinProjektname die Leerstelle ist wichtig.
    Kannst auch einen anderen Name ausdenken, hab ich noch nicht ausprobiert aber müsste auch funktionieren. Ich hab mein DataSet aber lieber im Hauptnamespace, weil ichs ausm Framework gewohnt bin.

    Das DataSet hat am Excel dann aber ja nichts kaputt gemacht, was du aber nach Post 27 immer noch angemerkt hast.

    Sorry, ja Du hast recht, Deine Beispiel-Excel-Tabelle wird weiterhin generiert, hätte ich schreiben schreiben müssen. Habe dies vergessen, da mich
    die Namens-Verdoppelung so sehr nervt. Und - es tut mir leid - die von "Löffel" vorgeschlagene Lösung hatte ich schlichtweg nicht verstanden.
    So wie Du es zusammen gefasst hast, aber sehr wohl. Trotz der vorgeschriebenen Leerstelle hinter dem Punkt (siehe Dateianhang) funktioniert es aber
    dennoch nicht. Jetzt mahnt VS an, dass der Typ "WinFormsNetVB.Dataset1" nicht definiert sei. Und auch die vorgeschlagenen Korrekturen lösen
    das Problem nicht. Denn die Entwurfsansicht des MainForm lässt deshalb nicht mehr darstellen, so dass ein Weiterarbeiten am Formular nicht
    möglich ist :( .
    Bilder

    • ScreenTransfer1.jpg

      407,1 kB, 1.920×1.080, 48 mal angesehen

    Versuche das DataSet nochmal vom Form zu schmeißen und neu draufzuziehen. Dazwischen vielleicht auch kompilieren und VS neustarten. Vielleicht sitzt da irgendwo was quer.

    Wie schaut im Objectexplorer dein Projekt aus?
    Zur Kontrolle vielleicht auch kurz die DataSet.Designer.vb checken.
    Bilder

    • objexp.png

      4,89 kB, 324×142, 57 mal angesehen

    • DSDesigner.png

      28,91 kB, 402×392, 64 mal angesehen

    Habe Dataset gelöscht, VS geschlossen, neu kompiliert. Excel-Tabelle wurde wie in Deinem Ur-Programm geladen.
    In dem Moment, wo ich versucht habe, eine Verbindung des DGV mit dem (einem neu hinzugefügten) Dataset aufzubauen, "crashte"
    VS, also stürzte ab (Rechner lief allerdings noch). Die jeweils letzte Botschaft war diese:
    Ich versuche später, von Deinem Ursprungsprogramm wieder aufzubauen X(

    Rechts daneben die beiden erbetenen Sreenshots.
    Bilder

    • ScreenVorCrash.jpg

      302,73 kB, 1.920×1.080, 51 mal angesehen

    • ScreenA.jpg

      385,91 kB, 1.920×1.080, 56 mal angesehen

    • ScreenB.jpg

      218,13 kB, 1.920×1.080, 60 mal angesehen

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

    Da hat er ja aber immer noch irgendwo den doppelten Namespace sitzen, deswegen wäre ein Blick in den Objectexploerer sinnvoll.
    Ist dieser Namespace wirklich noch vorhanden, oder hat sich in deinem Projekt irgendwo die Referenz abgespeichert und es ist jetzt nicht mehr vorhanden und deswegen meckert er?

    Ich weiß auch nicht was das sein könnte.

    Ich habe seit Tagen das Gefühl, mich im Kreis zu drehen.
    Entweder der Form.Designer generiert keine Entwurfsansicht (siehe Screenshot D) -> (Folge: Ich kann am Programm nichts
    mehr erweitern bzw. auf der graph. Oberfläche arbeiten), das Erstellen der Excel-Tabelle funktioniert aber.
    Oder die Entwurfsansicht funktioniert für einige Arbeitsschritte, es wird aber wieder der "Doppelname"
    generiert, obwohl ich im Namespace jenen "Global. [Projektname]"-Eintrag (siehe Screenshot C) vorgenommen habe. Frust !
    Bilder

    • ScreenD.jpg

      235,42 kB, 1.920×1.080, 52 mal angesehen

    • ScreenC.jpg

      100,5 kB, 1.920×1.080, 45 mal angesehen

Facebook
Telefonspende