Negative Werte in Enum

Hi,

ich weis nicht ob ich mich nur zu blöd anstelle oder ob ich ne fundamentale Funktion übersehe oder ka. Geht um folgendes:

Ich schreibe grad nen LV-Wrapper für die Ansteuerung eines Analyseprograms. Dadurch habe ich quasi alle Ein- und Ausgabedatentypen und mögliche Werte bereits vorgegeben. Nun habe ich an einer Stelle nen mehr oder weniger streng typisierten Eingang der die Werte -1 bis 2 annehmen kann (steht für verschiedene Dateitypen). Das ganze würde ich sinnvollerweise gerne als Strikt typisiertes Element mit nem Enum nachbauen. Dummerweise lässt mich das nur unsigned Datentypen auswählen und ich kriege das auch nicht dazu was anderes zu machen als von 0 hochzählend die Werte festzulegen (wäre ja nicht so schlimm, nur das ich eben -1 nicht reinkriege).

Klar könnte ich stattdessen nen Menüring nehmen (der auch signed Datentypen erlaubt und die Zahlen frei festlegen lässt) - nur bei dem werden Cases nicht automatisch erstellt und das wäre schon praktisch wenn man es direkt sinnvoll so nutzen könnte. Gibt es da irgendeine Möglichkeit das zu lösen? Bin ich da vielleicht auch grad iwie nur vernagelt und übersehe iwas?

Gruß Kiesch

P.S: Habe auch schon überlegt als workaround den Numeric zu nehmen, alle Zahlen die weitergegeben werden müssen +1 zu nehmen, so dass ich statt -1 0 benutze etc. also 0-3 und intern bei der Übergabe an das Analyseprogram ne Typumwandlung auf I32 mache und ein Dekrement, aber das ist auch nicht wirklich befriedigend.

Anzeige

Enum als Datentyp in LabVIEW ist unsigned, da kommst du nicht drum herum. Ich würde zur "minus 1" Lösung tendieren.

Gruß, Jens

Hi,

hab grad auch noch gemerkt, dass ich weitere strikt typisierte Datentypen brauche die teils auch Auslassungen bei den Zahlen drin haben (war glaube 1, 4, 5 und sowas) - das müsste ich im Enum dann ja als "leere" Enums (2 und 3) darstellen da der nur sequentiell hochzählen kann. Empfinde das als total störend und werde deswegen die Enum Lösung wohl definitiv nicht machen.

Gibt es denn noch eine andere Lösung bei der man die Cases automatisch bezeichnen lassen kann? Bin ansonsten jetzt alternativ versucht das dann doch einfach als Menüring zu machen (was für die Handhabung vermutlich erleichtert) oder als LVOOP Objekt (wie den rest von dem Wrapper) wo ich dafür die Möglichkeit hätte Datenkonsistenz zu erzwingen.

Also nochmal zusammengefasst: Gibts noch ne Lösung die auch das automatische Case erstellen und bezeichnen erlaubt und nicht nur auf sequentiell von 0 hochgezählte Integer Werte abzielt?

Gruß Kiesch

(14.11.2014 12:50 )Kiesch schrieb:  Hi,

hab grad auch noch gemerkt, dass ich weitere strikt typisierte Datentypen brauche die teils auch Auslassungen bei den Zahlen drin haben (war glaube 1, 4, 5 und sowas) - das müsste ich im Enum dann ja als "leere" Enums (2 und 3) darstellen da der nur sequentiell hochzählen kann. Empfinde das als total störend und werde deswegen die Enum Lösung wohl definitiv nicht machen.

Gibt es denn noch eine andere Lösung bei der man die Cases automatisch bezeichnen lassen kann? Bin ansonsten jetzt alternativ versucht das dann doch einfach als Menüring zu machen (was für die Handhabung vermutlich erleichtert) oder als LVOOP Objekt (wie den rest von dem Wrapper) wo ich dafür die Möglichkeit hätte Datenkonsistenz zu erzwingen.

Also nochmal zusammengefasst: Gibts noch ne Lösung die auch das automatische Case erstellen und bezeichnen erlaubt und nicht nur auf sequentiell von 0 hochgezählte Integer Werte abzielt?

Gruß Kiesch

Nein!
Da musst du wohl oder übel mit einem Ring arbeiten und damit leben, dass du im Sourcecode bei Case-Strukturen Zahlen stehen hast. Musst halt die Cases selber dokumentieren.

Gruß, Jens

Ginge das nicht auch mit einer Enum und einer Lookup-Tabelle (hier: einer einfachen Array-Konstanten) zu lösen?
Beispiel: Das Enum enthält die Einträge "A","B","C","D". Original sind diesen Einträgen die Werte 0,1,2,3 zugeordnet. Über die Lookup-Tabelle (= Array-Konstante) ordnest Du diesen Werten als neue Werte z.B -1,0,4,7 zu.

Hi Lucki,

ja im Prinzip hab ich an genau sowas auch schon gedacht. Das ist aber eigentlich grade nicht in meinem Sinne, aber auf irgendeine solche Lösung wird es wohl am Ende hinauslaufen. Der Hintergrund warum ich das eigentlich nicht will:

Der Wrapper ist für ein Analyseprogram, dass über ActiveX gesteuert wird und einfach nur alle ActiveX Aufrufe in LV Objekten und Methoden Kapseln soll. Wenn da mal jemand dran arbeiten muss weil sich was geändert hat (und das eventuell nichtmehr ich bin), wäre es ganz praktisch wenn derjenige sich einfach auf das Manual zu dem Program beziehen kann und nicht Workarounds wie diesen erklärt bekommen muss (sprich: von mir irgendwo als Info aufgeschrieben). ^^

Aber wie gesagt: Wahrscheinlich wird es trotzdem auf sowas in der Richtung hinauslaufen. Die Alternative wäre das ganze einfach garnicht ordentlich zu machen sondern nur als Standard I32 zu lassen (wie es aus den ActiveX Properties bzw. Methoden rauskommt / reingeht). Aber na ja... wenn schon machen dann ordentlich. Ich überleg mir was und werd mal schonmal die Lösungsvorschläge markieren. Werd dann nochmal Rückinfo geben was ich letztlich gemacht habe. War auch am überlegen ob ich die direkt als Objekte bauen sollte, damit sollte ich auch hinreichend gut erzwingen können, dass konsistente Eingabedaten in das Program reingehen und das das ganze wenns erweitert werden sollte (weil sich was im Analyseprogram ändert o.ä.) auch konsistent bleibt.

Wenn doch noch jemand nen anderen Vorschlag hat, nehm ich den dankend entgegen :-)

Gruß Kiesch

Anzeige

Update:

Hab mich jetzt entschieden wie ich das löse:

Die Controls bleiben Enums mit von den Zielwerten abweichenden Werten. Dazu hat jetzt jeder Zustand des Enums eine Klasse gekriegt, die alle von einem entsprechenden Parent erben. Über Dynamic Dispatching wird der eigentliche Zielwert entsprechend der Klasse ausgegeben.

In der Elternklasse ist entsprechend nen Zugriffsvi drin, dass die Labview Typedef in die entsprechenden Zielwerte umwandelt. Dabei wird on the fly nen Klassenobjekt erstellt und ausgewertet. Das entsprechende VI wird dann einfach im Wrapper genutzt.


Dürfte zwar nicht die schnellste Variante sein, aber hoffentlich die robusteste, die auch im Nachgang genügend Möglichkeiten bietet.