Variierende Komma-Interpretation

Hallo liebes LabVIEW-Forum,

ich melde mich hier mit einem kleinem Problem, welche eine große Auswirkung nach sich zieht.

Ich habe mir ein LabVIEW-VI erstellt, welches mir csv-Dateien von einem Ordner in eine einzige xlsx-Datei schreibt. Dabei wird der Inhalt jeder csv-Datei in ein Excel-Blatt (Sheet) kopiert. Der Code funktioniert auch bis auf die Tatsache, dass die Kommas nicht immer korrekt interpretiert und kopiert werden. Aus dem eingelesenen Wert "3641,223" wird in der xlsx-Datei "3641223", der Wert "3695,16" wiederum wird korrekt interpretiert (vermutlich liegt es an den nur zwei führenden Nachkommastellen). Ich hatte schon im Netz und im Forum nach ähnlichen Problematiken gesucht und bin auf die Option des landestypischen Dezimaltrennzeichens gestoßen. Diese war jedoch in den Optionen bereits aktiviert.

Excel als Ursache konnte ich ausschließen, da es normalerweise die Windows-Einstellungen bezüglich Trennzeichen verwendet und dort war ausdrücklich das Komma ausgewählt.

Habt ihr eine Idee, woran es liegen könnte? Den Code und Beispieldateien habe ich im Anhang hochgeladen.

Vorab vielen Dank und schöne Grüße
EinVolvic

Hallo Vulkanwasser,

Zitat:Habt ihr eine Idee, woran es liegen könnte?

Ja.
Das ist alles dein Fehler!

Im Ernst:
Du versuchst, Zahlenwerte zu lesen. Leider liest du die aber als Text ein - und schreibst sie auch als Text in die neue Excel-Tabelle.
Und das Excel dann gern mal durcheinander kommt, ist verständlich: wie soll man schließlich so komische Texte mit irgendwelchen Kommata darin sinnvoll interpretieren?

Vorschlag:
Arbeite doch einfach mal mit "echten" Zahlenwerten!

(Anmerkung am Rande: Ich bevorzuge ja im technisch-wissenschaftlichen Bereich die strikte Anwendung englischer Zahlenformate, d.h. Punkt als Dezimaltrennzeichen. Eine der ersten Einstellungen, wenn man einen neuen Windows-Account anlegt…)

Ein klein wenig - obwohl eigentlich On-Topic:

Mit der RGT-Excel-API in LabVIEW eine simple csv-Datei einlesen, das ist auch mit Kanonen auf Spatzen geschossen.

--

Zu Gerd's Erklärungen noch ein Nachtrag: Bei ActiveX will Excel heim zu Mama, soll heißen Redmond. Plötzlich ist das Komma in Texten mit Zahlen das Tausender-Trennzeichen, nur ein Punkt gilt als Dezimaltrennzeichen. Und schon hast du den von dir entdeckten Effekt.

Gruß, Jens

Hallo GerdW und jg,

danke für die zügige Antwort.

Ja, der Programmierer selbst ist die größte Fehlerquelle

Zitat:Vorschlag:
Arbeite doch einfach mal mit "echten" Zahlenwerten!

Du hast Recht mit den echten Zahlenwerten, das kann man auch relativ einfach umsetzen, indem man dem Einlesen-VI statt dem String-Array ein Double-Array übergibt. Aber das VI für das Schreiben in die XLSX-Datei nimmt leider nur Strings an. In dem VI habe ich keine Möglichkeit gesehen, dies zu ändern. Ich könnte auch selbst in die Zellen schreiben, aber das scheint mir nicht so effizient wie das vorhandene VI zu sein.

Zitat:(Anmerkung am Rande: Ich bevorzuge ja im technisch-wissenschaftlichen Bereich die strikte Anwendung englischer Zahlenformate, d.h. Punkt als Dezimaltrennzeichen. Eine der ersten Einstellungen, wenn man einen neuen Windows-Account anlegt…)

Kann man auch machen, dann hättest du das Problem auf jeden Fall nicht bekommen.

Zitat:Mit der RGT-Excel-API in LabVIEW eine simple csv-Datei einlesen, das ist auch mit Kanonen auf Spatzen geschossen.

Stimmt, das könnte ich noch optimieren oder eine Unterscheidung zwischen csv- und andere Dateitypen machen.