LabVIEWForum.de - Problem mit Case-Struktur

LabVIEWForum.de

Normale Version: Problem mit Case-Struktur
Du siehst gerade eine vereinfachte Darstellung unserer Inhalte. Normale Ansicht mit richtiger Formatierung.
Guten Tag zusammen.

Ich habe eine Case-Struktur mit numerischen Selektor, mit dem ich wählen will,
in welches Format ich eine Zahl konvertiere, um beim serialisieren die Länge eines HEX-Strings
zu bestimmem.
Dazu ist in jedem Case die Zahl durchgeschleift mit jeweils U8, U16, U32 dazwischen.
Dies führt zu dem komischen Problem, dass derjenige case "gewinnt", der die höchste Konvertierung
hat.
Auch wenn der Selektor z.B. Case 1 wählt, also U8 gewählt werden müsste, wird in U32 (Aus Case3) konvertiert.
Lasse ich den Selektor auf 1 und ändere z.B. Case2 auf U64, wird am Ausgang die Zahl auch U64 haben.
Die Tunnel der Cases mit der niedriegeren Konvertierung haben am Ausgang auch einen roten Pfeil (Autokonvertierung).

Das gleiche passiert übrigens auch bei "Typumwandlung".

Wieso "sehen" sich die Cases ? Wie kann ein Case einen anderen beeinflussen ?



Gruß,
Andre
Hi Andre

Der Draht, der aus der Case-Struktur herausgeführt wird, kann halt nur einen bestimmten Datentyp haben! Da er auch die Daten mit dem größten Datenumfang weiterleiten können muss, wird auf genau diesen gecastet.

Als Alternative kommt der Datentyp Variant in Frage, der alle Daten beinhalten kann. Der Preis ist die expilzite Konversion, wenn Du die Daten in dem Variant an anderer Stelle wieder benutzen möchtest.

Die andere Alternative ist die Benutzung von Klassen (LVOOP). Die verschiedenen Datentypen würden in diesem Fall als Kindklassen einer Basisklasse implementiert.

Gruß Holger
Es ist so wie Holger gesagt hat. Wenn Du ein Problem hast bei der Umsetzung, dann lad' einfach mal Dein VI hoch.
Ich hab' den Sinn des Ganzen noch nicht so wirklich verstanden, wieso Du mit so vielen Datenformaten herumkonvertierst.

Gruß Markus
Hier gibt es doch eine einfache Lösung, gewissermaßen das Ei des Columbus:
Wenn die ganze Übung dazu dient, die Länge des Hex-Strings für die Serialisierung zu bestimmen. dann kann man doch auch gleich den Hex-String in den einzelnen Cases erzeugen. Dann hätte man den einheitlichen Datentyp "String" für alle Case-Ausgänge, und außerdem wäre die String-Konvertierung, die sowieso ansteht, bereits erledigt.
Hallo und danke für die Antworten.

Das mit den Strings hab ich so gemacht, weil den Selektor auch noch für einiges andere
brauche, und das so halbwegs geordnet machen konnte.
Sonst könnte ich auch einfach in den längst-möglichen String konvertieren und mir die passenden
Stellen rausschneiden.

Das Problem war halt nur, dass mir unverständlich war, wie Änderungen in einem Case einen anderen
Case beeinflussen können, da die sich ja eigentlich - durch die Natur der Case-Struktur - ausschließen
sollten.
Aber die Antworten waren doch sehr einleuchtend.

Danke, Andre
Referenz-URLs