Falscher Datentyp in Kontexthilfe

Hallo zusammen,

Mir ist vor einiger Zeit aufgefallen, das bei einem Vi der Typ eines Controls nicht zum beschriebenem Typ in der Kontexthilfe passt.

Der Typ des Controls ist ein StrictTypeDef bestehend aus einer ComboBox (Bild1). Wenn ich mir den Datentyp in der Hilfe ansehe, listet er allerdings die Elemente eines Errorclusters auf. Diese Diskrepanz ist vermutlich auch der Grund für den coercion dot. Es bleibt auch nach erneutem Öffnen des Projektes dabei.

Ist einem von euch so etwas schon mal begegnet und was kann der Grund dafür sein?

Thomas

PS: In dem Beispiel werden zwar G#-Klassen benutzt, aber das Problem selber hat (vermutlich) nix mit OOP zu tun. Wenn doch, würde ich einen Moderator bitten diesen Beitrag zu verschieben.

Anzeige

Ja das ist normal... das eine ist eine Control Type der aber als Datentyp String hat, das andere ist eben nur ein String. Das Control Combobox definiert keinen eigenen Datentyp (so mit abgleich aller Eigenschaften), also nicht so wie z.b. ein Typedef eines Enums. Mglw. kannst Du mit Coerce to type an dieser Stelle den coercion dot entfernen. Bringt dir aber hier keinen echten Nutzen oder besondere Typechecks.

P.S.: Ich kenne das G# nicht im Detail, aber die Combi by-Ref-Klasse mit Get->Set Pattern sieht nach Race-Condition aus.

(24.11.2014 11:48 )macmarvin schrieb:  Ja das ist normal... das eine ist eine Control Type der aber als Datentyp String hat, das andere ist eben nur ein String. Das Control Combobox definiert keinen eigenen Datentyp (so mit abgleich aller Eigenschaften), also nicht so wie z.b. ein Typedef eines Enums. Mglw. kannst Du mit Coerce to type an dieser Stelle den coercion dot entfernen. Bringt dir aber hier keinen echten Nutzen oder besondere Typechecks.

Dass der String einen coercion dot erzeugt ist klar, aber warum erkennt die Kontexthilfe nicht den eigentlichen Typ des Terminals? Sollte dort nicht strict type def stehen statt der Elemente eines Errorclusters?

Zitat:P.S.: Ich kenne das G# nicht im Detail, aber die Combi by-Ref-Klasse mit Get->Set Pattern sieht nach Race-Condition aus.

Das Problem ist bekannt. Allerdings treten diese nur dann auf, wenn das Vi genau zwischen Get und Set unterbrochen und ein anders zusätzlich Set aufruft, so dass sie Daten aus dem Get veraltet sind. Wir haben bisher nur ein Projekt gehabt, wo das tatsächlich ein Problem wurde. Es ist aber auf jeden Fall unschön und steht auf unserer ToDO-Liste.

Thomas