Moin moin,
ich verwende die Funktion "In String suchen" um aus einem String einige Daten zu extrahieren.
String:
p0="false" p1="33.3"
FormatString:
p0="%s" p1="%.;%f"
Gewünschte Daten:
BOOLEAN p0=false
DOUBLE p1=33,3
Leider liest LabVIEW das Anführungszeichen hinter %s mit ein und ich erhalte:
BOOLEAN p0=false"
Danach passt der Rest natürlich nicht mehr und ein DOUBLE-Wert wird nicht gefunden. Wenn ich aus dem FormatString das Anführungszeichen entferne klappt es, allerdings ist das Anführungszeichen dann im Ergebnis vorhanden.
String:
p0="false" p1="33.3"
FormatString:
p0="%s p1="%.;%f"
Daten:
BOOLEAN p0=false"
DOUBLE p1=33,3
Kann mir jemand einen Tipp geben? Die Alternative mit "Muster Suchen/Match Pattern" ist unschön, da im String zu viele Daten liegen!
Kleines Beispiel (sind natürlich viel mehr Daten im echten Projekt):
[
attachment=44613]
Danke und Grüße,
Totti
Hallo Totti,
so geht's:
[
attachment=44614]
Du musst bedenken:
-"%s" kann bei "false" nur den String false" (mit Anführungszeichen) liefern (Strings werden an Whitespaces getrennt!) und ScanFromString meldet dann einen Fehler aufgrund des dann fehlenden Anführungszeichens im Suchstring...
- Ich bin mir grade nicht sicher, ob "false" (ohne Anführungszeichen) als boolscher Wert erkannt wird. Auf jeden Fall müsstest du aber als Formatcode das %b verwenden und eine boolsche Konstante als Default für ScanFromString vorgeben. Die Kontexthilfe jedenfalls zeigt diese Möglichkeit nicht auf...
Heißt also, wenn mein String keine Leerzeichen enthält, habe ich keine Chance?
Es gibt beim %s noch das Argument der Länge (%ns, liest n Zeichen), aber bei TRUE und FALSE ist das eben auch doof.
Hatte schon überlegt, im String einfach TRUE durch 1 und FALSE durch 0 zu ersetzen. Aber was mache ich, wenn ein Argument dann TRUEmmerhaufen heißt? Dann passt mein Formatstring wieder nicht. Werde als das Anführungszeichen mit lesen.
Danke für die Hilfe,
Totti
Hallo Totti,
dann ersetze doch "true" durch 1 und "false" durch 0: bei den Strings jeweils mit Anführungszeichen, die Zahlen ohne.
Jetzt hast du nur Probleme, wenn du gemischt Lower/UpperCase-Strings bekommst...
Gute Idee! Meine man könnte beim Suchen und ersetzen auch "case-sensitive" deaktivieren! Schaue ich mir mal an! Danke!
Das Problem ist doch, dass die Strings "true" und "false" unterschiedlich lang sind. Aber nicht für jemanden, der auch vor Brutalitäten (sprich: Fehlerbehandlungen) nicht zurückschreckt:
[
attachment=44616]
Oder ohne lokale Variablen:
[
attachment=44617]
:-) Auch nett! Habe mich aber dazu entschieden, sowohl FormatString als auch InputString zu manipulieren. Aus "fAlSe" wird "0" und aus "TrUe" wird "1"!
[
attachment=44623]
Als nächstes versuche ich mich mal an einer echten XML-Interpretation!
(14.05.2013 12:43 )TSchAC schrieb: [ -> ]sowohl FormatString als auch InputString zu manipulieren. Aus "fAlSe" wird "0" und aus "TrUe" wird "1"!
Das ist allerdings so einfach, dass man annehmen musste, du wärest da von Anfang von selbst darauf gekommen und hast die Frage nur gestellt, weil eben diese Änderung des Eingangsstrings nicht in Deinem Ermessen steht. Deshalb hatte ich von Gerd die "richtige" Antwort in dieser Richtung auch nicht ernst genommen. Aber mit dem menschlichen Gehirn ist es eben so eine Sache, keiner weiß richtig wie es in einem anderen tickt..
Hatte gehofft, dass man sowas wie %/";s angeben kann! Quasi einen String der nicht mit Leerzeichen sondern vorm nächsten Anführungszeichen endet!
Und ich hatte den Knoten im Kopf, dass ich den FormatString nicht manipulieren kann! Daher die bedenken, dass das Ganze schief geht, wenn ich unbeabsichtigt einen "Truemmerhaufen" in ein "1mmerhaufen" verwandel!
Die ErrorMethode ist übrigens auch nicht mehr sooo schön, wenn der Eingangsstring länger wird!
Nungut, ich übe mal XML! Da ist LabVIEW ja auch irgendwie eigen, bzw. meine Wünsche und Vorstellungen sind anders als LabVIEW.
LabVIEW hat doch inzwischen einen vollständigen XML-Parser an Bord:
[
attachment=44626]
Gruß, Jens