LabVIEWForum.de

Moinmoin...

Vorweg (1):
Mich nervt es, dass hier immer wieder von Exceldateien erzählt wird, die beim Nachfragen zu ASCII/CSV Dateien mutieren oder im Zusammenhang mit dem "Write to Spreadsheet VI" von Exceldateien geredet wird.
Hier also der Rundumschlag um ein für alle Mal klarzustellen was eine Exceldatei ist.

Vorweg (2):
Ich will mich ja nicht mit fremden Lorbeeren schmücken, daher der Hinweis auf diesen CodeProject Artikel.
Serhiy Perevoznyk hats ausgefuchst, ich habs portiert

Also was ist das?
Direktes Erstellen einer nativen (binären) Exceldatei in BIFF5 (Binary Interchange File Format Version 5) ohne Excel Automation oder das Einbinden von 3rd-Party dll's.

Pro:
Ein installiertes Excel ist auf dem ausführenden Rechner nicht nötig.
Exportieren von Double-, Integer- und String-Werten.
Es ist schneller als Excel Automation.

Contra:
In dieser Version keine Formatierung der Zellen.
Wer kann und möchte, kann das ja nachrüsten.
Links zu den Spezifikationen: OpenOffice: Excel Spezification und Microsoft: Excel Spezification

Wofür braucht man das?
Ich benutze das schon länger in meinen VB.net Projekten, um schnell große Datenmengen zu exportieren. So in der Größenordnung mehrere 10000 Zeilen und 100+ Spalten. Auf eine Formatiertung kann ich dabei verzichten, da es um die Daten zu Weiterverarbeitung geht und nicht um Kundenreports.

Wie benutzt man das?
Für LV hab ich die Funktionen Start/Stop und ein polymorphes VI zum schreiben einer Zelle erstellt.
[attachment=26897]

Beispiel:
snip09
[attachment=26896]

Dateien:
[attachment=26899]
[attachment=26898]
Lizenz:
Genauso wie der C#-Code stehen die LV-VI's unter der The Code Project Open License (CPOL) 1.02 zur Verfügung.

Letzte Worte:
Viel Spaß damit.
Wer was verbessert, darf es natürlich gerne hochladen...


Gruß SeBa

Danke.

Gruß Markus

Hallo SeBa,

nach erstem Rumprobieren: schöne und (Hauptvorteil) Excel-freie Lösung!

Werde, sobald Zeit ist, noch etwas Fehlerhandling implementieren und dann hier wieder hochladen...

Gruß

' schrieb:Werde, sobald Zeit ist, noch etwas Fehlerhandling implementieren und dann hier wieder hochladen...

Tob dich aus...

Gruß SeBa

Hallo zusammen,

ein erstes Update...

- einige Fehlerabfragen eingeführt
- Funktionen zum Schreiben von Booleans und Fehler-Anzeigen zugefügt
- Write_DBL erweitert, da Excel nicht alle IEEE-Codes kennt (NaN)
- Write_String auf 255 Zeichen begrenzt (bin mir bei der Doku aber noch nicht sicher, ob diese Grenze richtig ist...)
- Projekt und lvlib erstellt
- häufige Operationen als lvlib-interne Routine ausgeführt
- 4:2:2:4 connector pane, teilweise Eingänge als "required" markiert
- einige wenige Kommentare hinterlassen
- VIs teilweise umbenannt (Start, Close)
- deutsche Captions entfernt, englische Labels anzeigen lassen

Bin für Vorschläge und Kommentare offen.

Frage:
- Sollen Fehlerabfragen nur intern durchgeführt werden (z.B. der Test auf korrekte row/column-Angaben) oder auch per ErrorCluster gemeldet werden?
- Wie soll bei DBL mit ±Inf verfahren werden?

(vorerst)

Oh je...

...jetzt wirds hart. Da kommt meine vollkommene Unwissenheit bezüglich Projekte zum tragen.

Du hast die Begin/EndWrite VIs und das Write_polymorph umbenannt und in die lvlib reingepackt... braucht man die originalen dann überhaupt noch?
Davon abgesehen, dass beim draufklicken gemeckert wird...
[attachment=27019]


Was genau bringt lvlib jetzt (sorry, kein Plan... Kurze Erklärung reicht)?
Warum 4:2:2:4 con.pane?


So:
Alle Zellen sind 2080byte begrenzt, ist der Inhalt größer, muss ein CONTINUE Record geschreiben werden. ...ToDo
Fehlerabfragen würde ich auch rausgeben, z.B. row/col OutOfRange -> Abbruch aller folgenden Schreiboperationen + ErrorOut
DBL±Inf. muss mal reinlesen, ob es dafür einen Record gibt, sonst würd ich vorschlagen Max/Min DBL einzuschreiben.


Gruß SeBa

Hallo SeBa,

"Davon abgesehen, dass beim draufklicken gemeckert wird..."
Muss ich mir heute abend (ehm, heute Anpfiff - dann später am Wochenende: ehm Sonntag spielt Deutschland - evtl. nächste Woche...) nochmal anschauen! Bei 30° dann doch lieber PublicViewing in der (irischen) Lieblingskneipe...
Edit: Nach einem Blick ins ZIP-File: Die VIs mit altem Namen sind Überbleibsel vom Umbenennen. Anscheinend hat LV nicht umbenannt, sondern kopiert... Umbenennen funktioniert sonst eigentlich sehr gut im Projekt. Muss mit der lvlib-Verknüpfung zusammenhängen. Umbenannt hatte ich, um konform mit sonstigen Funktionen (wie bei normalen Dateien) zu werden bzw. um den User nicht zu verwirren (der braucht nicht unbedingt ein VI mit Namen "*_polymorph").

"Was genau bringt lvlib jetzt (sorry, kein Plan... Kurze Erklärung reicht)?"
Zusammenfassen von zusammengehörigen Funktionen, mit der Möglichkeit, Funktionen als "Privat" zu deklarieren. Bin auch am Ausprobieren...
Edit: Guckst du hier, 2. Absatz.

"Warum 4:2:2:4 con.pane?"
StyleGuide-konform.
Edit: LabVIEW-Cleanup liebt gerade ErrorCluster-Drähte. Ich liebe gleichmäßig ausgerichtete Icons. Standardfunktionen bevorzugen den 4224-ConPane. Schmeiß alles zusammen, und du verstehst, warum alle (ok: 99%) meiner VIs den 4224-ConPane verwenden...

"Alle Zellen sind 2080byte begrenzt ...ToDo"
Ich hatte in der Beschreibung von MS noch eine andere Zahl gelesen. Kann aber sein, dass sich diese auf BIFF7/8 bezog. Außerdem hat mein Excel2000 von einem 1023 Zeichen langen String nur die ersten 255 Zeichen angezeigt (der Rest wurde als Leerfeld präsentiert) und beim Löschen des letzten (unsichtbaren) Zeichens automatisch auf 255 Zeichen verkürzt...

"Fehlerabfragen würde ich auch rausgeben"
Werde ich noch einbauen.

"DBL±Inf ... Max/Min DBL einzuschreiben"
Excel macht aus +Inf automatisch 1.xE+308 (=MaxDBL), -Inf hatte ich gestern abend nicht mehr ausprobiert. Aus NaN macht Excel2000 übrigens 2*+Inf

Ich werd' dran bleiben!

' schrieb:"DBL±Inf ... Max/Min DBL einzuschreiben"
Excel macht aus +Inf automatisch 1.xE+308 (=MaxDBL), -Inf hatte ich gestern abend nicht mehr ausprobiert. Aus NaN macht Excel2000 übrigens 2*+Inf

Hab mich heute in der Mittagspause mal damit beschäftigt und folgendes nachgerüstet:
[attachment=27057]

Bringt mich dann zu der Frage:
So einen Enum dann lieber als .ctl und strict-type-def. oder doch so wie deinen Error-Enum direkt in das VI integrieren?

Andere Frage zum Dateimanagement wäre dann noch, ob man private Dateien in einen extra Ordner speichert... ggf. .ctl's auch?

Hab außerdem die row/col verbunden im NaN Case für Write_DBL.

Zum Thema +-Inf. hab ich mich auch mal schlau gemacht, aber da unterscheiden sich die Excelversionen teilweise ganzschön in Bezug auf die Zahl die dann geschrieben werden müsste.

-Inf. wird bei meinem Excel 2002 SP3 ignoriert und genauso ausgegeben wie +Inf.

-> Daher der Gedanke, bei DBL auf +-Inf. zu prüfen und entsprechend einen String in die Zelle zu schreiben, statt der Zahl.
Was meinst du dazu?


[attachment=27058]


Gruß SeBa

Hallo,

noch ein Update vor'm Wochende:
- interne Änderungen (Fehlercode-Generierung und -Weitergabe)
- Errorcode-Generierung in (private) Subroutinen verlegt zur leichteren Erstellung weiterer Fehlermeldungen, ErrorCodes starten bei 9100
- Enum/Ring als public typedef
- DBL: ±Inf wird geprüft und als #VALUE weitergegeben
- I32: Test auf Excel-30bit-Beschränkung, ansonsten Verwendung von DBL
- readme.txt im Folder documentation angelegt

Gruß

Update

[attachment=27109]

-xlBin_Write_Note.vi
Beliebig lange Kommentare in einer Zelle speichern.
[attachment=27110]
Im xlBin_Write.vi hinter Write_String eingefügt, damit STR als Standardauswahl bleibt.

-xlBin_private_Error_Generator.vi
Array gegen Property ausgetauscht -> jetzt werden Änderungen am xlBin_private_Errorcode.ctl direkt übernommen.
[attachment=27111]
Oder war das vorher auch schon so? Wenn ja, dann bitte erklären

-xlBin_private_Check_RowColRange.vi
Eingang für FileRef, Ausgänge für FileRef, Row, Col hinzugefügt.
-> Weniger Knotenpunkte + gefällt mir besser
(StyleGuide konform?)
[attachment=27112]


Folgendes zur Diskussion bitte:
Bei Strings >255 Zeichen im LABEL-Record ist die Datei nicht lesbar. Das BIFF-Record Limit von ?2080 Bytes greift hier nicht. CONTINUE-Records scheinen nicht zu funktionieren (wenn man einen String >255 Zeichen als Excel5 Datei speichert, ist der String nach dem Laden nur 255 Zeichen lang...).
Folgende Möglichkeiten sind denkbar
1) String nicht schreiben und Error ausgeben (aktueller Stand)
2) Die ersten 255 Zeichen in die Zelle schreiben und Warnung/Error ausgeben
3) Die ersten 255 Zeichen in die Zelle schreiben und den Rest als NOTE-Record mit dem Hinweis "Der String war zu lang... Rest: blablabla"

Ich würde 3) favorisieren.



Gruß SeBa