Verständnisfrage (Bug?)

Hallo,

mir ist kürzlich beim Erstellen von XY-Graphen etwas merkwürdiges aufgefallen. Ich verwende bei Zahlenformatierungen oft den Ausdruck "%.;" um sicherzustellen,
dass egal wie Labview auf dem Zielrechner installiert wurde, in Anzeigen einheitlich der Dezimalpunkt als Trennzeichen verwendet wird.
Beim Formatieren der X-Achse eines Graphen mit X-Werten im Bereich 100 bis 100.01 fiel mir auf, dass "%.;%#_6g" etwas völlig anderes als "%#_6g%.;" liefert.
Bei ersterem fehlen sämtliche Zwischenbeschriftungen. Letzteres liefert das (von mir) gewünschte Ergebnis.
Hab das bei Labview 2012 (mit dem ich hauptsächlich arbeite) beobachtet, aber auch mit 2016 nachvollziehen können.
Ist das so gewollt? Ein Bug? Oder habe ich da irgendetwas übersehen?

Anzeige

(10.08.2018 16:23 )THL schrieb:  Ich verwende bei Zahlenformatierungen oft den Ausdruck "%.;" ...

Ich auch.

Zitat:X-Achse eines Graphen mit X-Werten im Bereich 100 bis 100.01

Genau so hab ich das auch ausprobiert.

Zitat:fiel mir auf, dass "%.;%#_6g" etwas völlig anderes als "%#_6g%.;" liefert.

Ich kann das nachvollziehen mit LV2014.
Allerdings scheint die Darstellung mit %.; am Ende auch falsch: Alle Zwischenwerte, also z.B. 100.004 sind doppelt. Es scheint nur so, weil die Zahlangabe eben auf 3 Nachkommastellen gerundet ist - aber doppelt ist eben nun mal doppelt.

Zitat:Ein Bug?

Bug zu unterstellen ist immer schwierig - eher ist es ein unsauber ausgearbeitetes Feature. Ich vermute, dass der Graph mit der ein Darstellung des Formatstrings nicht zurechtkommt, und deswegen ganz einfach die Zwischenwerte nicht anzeigt. Das ist dann kein Bug, sondern die Umgehung eines möglichen Bugs.

Mit %.3f%.; sind die doppelten Anzeigen weg. Die weggelassenen Nullen gefallen mir sowieso nicht ...

Zitat:Oder habe ich da irgendetwas übersehen?

Da wäre alles Spekulation:
Laut Beschreibung des Formats des Formatstrings beginnt der String mit dem %-Zeichen und endet mit einem Buchstaben. Alles dazwischen ist Eigenschaft zur Methode, die hinter dem Buchstaben steht. Es steht zwischen dem % und dem g aber ".;%#_6". Das kann der Eigenschafts-Auswerter nicht interpretieren => Nichts tun. Also: Beide Formats umdrehen ...

Hallo,

Zitat:dass "%.;%#_6g" etwas völlig anderes als "%#_6g%.;" liefert

Das %.; gehört laut Hilfe ja auch nach vorn im Formatstring, da es für die nachfolgenden Zahlenformate gilt...

(12.08.2018 07:29 )GerdW schrieb:  Das %.; gehört laut Hilfe ja auch nach vorn im Formatstring, da es für die nachfolgenden Zahlenformate gilt...

Ist schon klar - mache ich ja auch ... üblicherweise.
Aber wie beschrieben, wollte ich ein "#_6g" dazu bringen auf einem Zielrechner in einem XY-Graphen Dezimalpunkte, statt Kommata anzuzeigen.
Also (wie üblich) ein "%.;" vor die Formatierung gesetzt und erwartet, dass es wie sonst auch Komma gegen Dezimalpunkt tauscht und sonst nichts weiter macht.
Das Ergebnis war aber ein komplett anderes: Achsbeschriftung nur noch am Anfang und Ende ohne Zwischenbeschriftungen. Auch die Skalierung als solche veränderte sich.
So aus Jux und Tollerei habe ich dann das "%.;" hintenan gestellt und nicht wirklich erwartet dass das irgendeinen Effekt hat.
Dementsprechend war ich doch baff erstaunt, dass etwas anderes angezeigt wird.
Zwar auch nicht exakt das was ich erhofft habe, aber dennoch besser als die vornan gestellte Version.
Anbei ein Snapshot mit den verschiedenen Formatierungsstrings.

Hallo THL,

was passiert, wenn du die Skalierung "händisch" (über PropertyNodes mit Konstanten dran) einstellst?

Graphen sind einigermaßen "zickig" - ich musste auch gerade erst wieder einen ersetzen, weil sich die zweite Y-Achse ins Plotbild reingeschoben hatte…

(13.08.2018 11:48 )GerdW schrieb:  was passiert, wenn du die Skalierung "händisch" (über PropertyNodes mit Konstanten dran) einstellst?

Hat leider den gleichen (negativen) Effekt. In meinem Programm werde ich wohl bei "%#_6g%.;" bleiben - ist noch der beste Kompromiss.

Anzeige

Hallo THL,

habe nochmal etwas rumgespielt:
   
Allerdings verwende ich per default den Punkt als Dezimaltrennzeichen…