08-16-2021 03:04 PM - edited 08-16-2021 03:05 PM
My reply is specifically about one of the things you noted earlier - the note about LabVIEW "not supporting null characters for regular expression matching".
LabVIEW's string datatype is distinct from the standard C handling of strings in one very important way.
While a NUL character (that is, a byte value \00) is used by C standard library functions as the required end-of-string marker (remember, C passes a pointer-to-char and the callee needs to know where the string ends), in LabVIEW a NUL holds no special significance to nearly all LabVIEW string primitives. It's processed just like any other character value (though like most "control" character values, it's invisible or rendered as a meaningless blip in "normal" text displays).
The exception is the Match Regular Expression node, because that node is built on the PCRE regular expression library, which was built in, yup... C.
Offhand I'd say that 80+ percent of most casual LabVIEW users' string-processing tasks can be handled by the Match Pattern node, or Search and Replace String, or Scan String for Tokens, or some combination of those, perhaps requiring a simple loop. If you must use the PCRE Match Regular Expression, you will need to ensure your string data is sanitized so as not to contain embedded NUL chars.
Dave
08-17-2021 10:26 AM
Alex,
this looks more as the data I was looking for. I accepted this as a solution. I need to finetune it a bit but now I know how I shall parse the data.
The "search and replace string" (with right click) was new for me.
Thank you
08-17-2021 11:25 AM - edited 08-17-2021 11:29 AM
in the first stage it is probably better to replace with the "Empty String Constant",
and in the second stage with "End of Line Constant"