Convert cluster to readable string and string to data, but not UTF-8?

[1984]

I need to convert a cluster to a string in a way that it remains easily readable when probing a wire, and I later need to convert the string back to the original cluster. The solution should be generic, not custom made for a given cluster.

The conversion is not a problem, I convert the data to JSON or Flatten the data to string but JSON forces UTF8 (making some of the characters I use unreadable) and Flattent to String has poor readability overall.

I love how the data looks like when I convert the cluster to variant (structured and not UTF-8), but I cant connect it to a String indicator and the data I use between the conversion and a reverse conversion must be string. Would be nice to to somehow achieve the same structure, but receiving getting the data as string and not as variant.

Is there an option fulfills all the requirments?

[wiebe@CARYA]

Yes, it's very annoying that those variant strings aren't accessible to users. A waste of good code AFAIC...

You (and everybody else) would have to use a serializer of some sort, recursively going over elements...

You could try an existing one,like GitHub - LabVIEW-Open-Source/Serializer: Serializer classes with emphasis on Key-Value pairing, either as a solution or as a starting point.

What could have been a 2 min. job (get the string from a variant) is now a never ending project. You start optimistically, and at some point you'll run into classes (that become empty when default), maps\sets, variants!, etc. . And of course if you want a different output you either have to copy everything and modify it, or make much more difficult output API...

A 'humbling" programming experience is guaranteed, although you'll only fully appreciate it when you think you're at 95%, while it's actually more like 10%.

[wiebe@CARYA]

Couldn't let this one go.

Here's a HACK.

Each and every disclaimer applies here.

But it does seem to work 😊, and I don't know why it shouldn't. Haven't tested it at all, but esp. using it in an exe should be tried before developing anything.

Developed in LV24, saved back to LV13, because "why not".

[1984]

---

A 'humbling" programming experience is guaranteed, although you'll only fully appreciate it when you think you're at 95%, while it's actually more like 10%.

---

Well said 🙂 I believe programmers experience these percentages far more often than they are willing to admit. 🙂 

Another option is to convert the UTF8 text to LVtext where the JSON is generated and before want to convert the text to data you convert the LVtext to UTF-8. I'm not sure all the implications but it works for sure for simple clusters. The caveat is that you must not forget converting the LVtext to UTF-8 everytime you need to convert the text back to data. If you forget than the text very likely will be converted to the datacluster with a "no error" error cluster, but the data might be corrupted.

[raphschru]

---

wiebe@CARYA wrote:

Haven't tested it at all, but esp. using it in an exe should be tried before developing anything.

---

Does not work in an exe. It is the same function called inside "UID to GObject Reference.vi" (Hidden Gems Palette).

It requires "labview.exe", which you can (obviously) not include in your build.

Regards,

Raphaël.

[wiebe@CARYA]

---

@raphschru wrote:

---

wiebe@CARYA wrote:

Haven't tested it at all, but esp. using it in an exe should be tried before developing anything.

---

Does not work in an exe. It is the same function called inside "UID to GObject Reference.vi" (Hidden Gems Palette).

It requires "labview.exe", which you can (obviously) not include in your build.

---

It indeed does not work in executables, but not for that reason.

If you change "labview.exe" to "LabVIEW", the RTE dll will be used in executables (automatically)

The exe will actually run, the function will be called, but sadly the function doesn't do anything. EDIT: The return value of the dll will be 53 (error "Manager call not supported"), not 0 (no error).

A lot of functions exported by LabVIEW.exe are supported by the RTE. Lots of those functions are actually used by LabVIEW internally, some even in vilib VIs (like the To\From JPG\PNG VIs).

So it's true, but not obvious.

[paul_a_cardinale]

Very nice.

But it doesn't work on a Mac.

And I hate the icon.

The attached version works with a Mac (and has a nice icon).

[wiebe@CARYA]

---

@paul_a_cardinale wrote:

Very nice.

But it doesn't work on a Mac.

And I hate the icon.

The attached version works with a Mac (and has a nice icon).

---

Now this function doesn't work (properly) in executables, so it's irrelevant, but I don't think the solution itself will work in a PC executable.

On PC, the function has to be a call to LabVIEW, and not the executable's name. The RTE will replace LabVIEW with calls to the LVTRE (lvrt.dll, IIRC).

If you've tested the trick, and if it works, I guess I have to add it to my bag of tricks.

[wiebe@CARYA]

BTW There is another way to get the variant data and type text, although in executables only the data text works.

More on that later...

[paul_cardinale]

What do you think of this?