Zahl nicht als Text in Excel schreiben

  • VB.NET
  • .NET (FX) 4.5–4.8

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von Bartosz.

    Zahl nicht als Text in Excel schreiben

    Hallo,
    mein Programm befüllt ein Excel-Sheet. Es sollen Kommazahlen mit deutscher Notation geschrieben werden. Daher habe ich
    xlRange.Value = Test.ToString(Deu) verwendet. In der Excel-Datei bekomme ich nun angezeigt, dass die Werte als Text gespeichert wurden. Wie kann ich die Werte direkt als Zahl speichern?


    VB.NET-Quellcode

    1. xlRange = CType(myWorksheet.Cells(Line + 1US, column), Excel.Range)
    2. xlRange.Value = Test.ToString(Deu)
    gib die Zahl als Zahl ein - nicht als string.
    wenn Excel die in einer anderen Kultur darstellt als du möchtest, sieh mal zu, Excel die gewünschte Kultur beizubringen.
    mich wundert das.
    eiglich sollte Excel die Kultur des Rechners übernehmen - so wie's VB ja aquch macht. Was man daran sieht, dass .ToString in der dir genehmen Kultur formatiert.

    hast du mal ein bildle, was passiert, wenn du einfach das .Tostring weglässt?

    kannst du nicht auch das CType weglassen? ich denk, myWorksheet.Cells(Line + 1US, column) ist bereits ein Range.
    @ErfinderDesRades Ich danke dir für deine Antwort.

    1.)
    Ohne ToString() klappt es tatsächlich. Ich war mir sicher, dass das Programm 21.1 statt 21,1 schreibt. (Also an alle die diesen Thread lesen. In C / C++ geht das jedenfals definitiv nicht ohne Kultur-Umwandlung!)
    ... Ok, das hat sich erledigt.
    Aber das Datum muss mit .ToString("Format", Provider) bearbeitet werden.

    VB.NET-Quellcode

    1. column = 1US
    2. xlRange = CType(myWorksheet.Cells(Line + 1US, column), Excel.Range)
    3. xlRange.Value = Date.Now.ToString("d", Deu)
    4. column = 2US
    5. xlRange = CType(myWorksheet.Cells(Line + 1US, column), Excel.Range)
    6. xlRange.Value = Date.Now.ToString("t", Deu)
    7. column = 3US
    8. xlRange = CType(myWorksheet.Cells(Line + 1US, column), Excel.Range)
    9. xlRange.Value = Test '.ToString(Deu)
    10. xlRange = CType(myWorksheet.Cells(Line + 2US, column), Excel.Range)
    11. xlRange.Value = Test '.ToString(Deu)
    12. xlRange = CType(myWorksheet.Cells(Line + 3US, column), Excel.Range)
    13. xlRange.Value = Test '.ToString(Deu)
    14. Line += 3US





    2.)
    Ohne
    CType meckert der Compiler, auch wenn Cells bereits ein Range ist. ?(


    Edit: Ich nutze übrigens Option Infer Off, damit ich immer schön den Typ hinschreibe. Ich mag dieses Dim lines = meinString.Split() nicht.

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

    Das ist das Doofe bei Interop.Office, da wird so ziemlich alles zu Objects verwurstet, weil die Functions aus der DLL quasi untypisiert weitermachen. Immer muss man selber casten, wenn man mit den Office.Dlls arbeitet.
    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.
    nö, glaub das ist nicht so. Man kann Excel einbinden, und dann gibts auch Intellisense, und Datentypen.
    WorkSheet.Cells() scheint eine Property des Datetyps Range zu sein.
    Un Range scheint eine Default-Property zu haben, wo man mit zwei Parametern was abrufen kann (ich glaub, ebenfalls einen Range - aber vielleicht auch was anderes).
    Was bietet Intellisense, wenn man die Default-Property ausschreibt?
    Probierma myWorksheet.Cells.Item( - ob und was Intellisense dann anbietet.
    Oder guck gleich in den ObjectBrowser - Intellisense ist ja eiglich nur quick & dirty.
    Man lese dies
    stackoverflow.com/questions/69…ave-to-convert-cells-here

    Zusammenfassung:
    Der statische Typ ist
    Object. Der Typ, den ich während der Laufzeit prüfe, ist plötzlich Range.

    Und Option Strict On fällt das auf. Das ist schonmal gut. So weiß man bescheid und muss Ctype() schreiben.

    Antwort:
    Dieses unglückliche Design könnte damit zusammenhängen, dass es sich um das Excel-Automatisierungsobjektmodell (Excel Automation object model) handelt, das meiner Erinnerung nach aufgrund vieler Altlasten nicht das freundlichste ist, mit dem man arbeiten kann.

    Es sieht so aus, als ob das Problem speziell bei Sammlungen liegt. Scheint, als ob fast jede Sammlung, auf die durch item zugegriffen wird, Object zurückgibt.

    Nein, Sie machen nichts falsch, so verhält sich die Excel-Automatisierungsschnittstelle. Insbesondere sind die Sammlungstypen alle die klassische VBA-Sammlung (oder das funktionale Äquivalent), was bedeutet, dass der Indexzugriff ein
    Object zurückgibt, und nichts, was stark typisiert ist.

    Bartosz schrieb:


    Ich war mir sicher, dass das Programm 21.1 statt 21,1 schreibt. (Also an alle die diesen Thread lesen. In C / C++ geht das jedenfals definitiv nicht ohne Kultur-Umwandlung!)


    Du kannst dir sicher sein, dass es auch genauso ist. Dazu brauchst du dir nur deine Excel-Datei mal in .zip umzubenennen, dann schaust du dir die Datei sheet1.xml im Verzeichnis \xl\worksheets\ mal genauer an.
    Warum das mit C / C++ nun anders sein soll, das weiß ich nicht. Ich vermute nur, dass du da einen anderen Weg gefunden hast, der vielleicht (Spekulatius) die GUI von Excel steuert. Sozusagen ein Paste in die Zelle macht? Keine Ahnung...

    Wenn du Excel von Hand über die GUI bearbeitest, dann musst du nach unseren Kulturvorgaben '5,1' schreiben, '5.1' (jeweils ohne die Hochkomma) wird als Datum interpretiert. Aber, in dem Excel-Workbook steht trotzdem dann wieder '5.1' in der Zelle. Probier's aus, dauert keine 2 Minuten.
    Also ich gebe direkt float, double oder decimal (meist decimal) aus und das wird auch so geschrieben.
    In Excel angezeigt wird dann entsprechend der @ErfinderDesRades im Post 2 auch schreibt gemäß unserer Kultur die dezimalstelle als Komma.
    Was du schreibst sit definitiv nicht richtig, debug doch mal dein Programm und schau dir den Value an der wirklich geschgrieben wird.
    In VB.Net ja
    Beim Debuggen sieht man zwar einen Punkt, aber in der Excel steht ein Komma. Wird auch valide als Zahl erkannt.
    Und das ist mir seit Post #2 auch bewusst. Ich dachte vorher, es sei nicht so.
    Bilder
    • Screenshot 2021-09-08 155312.png

      5,95 kB, 381×109, 59 mal angesehen
    • Vollbildaufzeichnung 08.09.2021 155239.jpg

      26,16 kB, 857×86, 54 mal angesehen
    Das ist nicht auf VB.Net beschränkt, guck doch mal in die Excel-Datei rein. Aber nicht öffnen sondern erst umbennen. Als Dateiendung ZIP statt XLSX nehmen. Dann kannst mit einem Zipper deiner Wahl reingucken, oder entpacken und gucken. Deine Float steht da so drinnen, wie das Framework es da reingeschgrieben hat, mit dem Punkt als Dezimaltrennzeichen. Lediglich die Computereinstellung CULTURE sorgt dafür, dass wir es "mundgerecht" sehen.

    Ein ganz anderer Vorteil am heutigen Dateiformat von Excel ist, dass es realtiv einfach ist die XML-Dateien ohne dafür im Hintergrund Excel selbst zu benötigen, schreiben kann. Wenn man das nicht selbst entwickeln will dann nimmt man z.B. EEPlus. Das schreibt Excel-Dateien ohne Excel auf dem Rechner selbst installiert haben zu müssen.