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

[wiebe@CARYA]

---

@paul_cardinale wrote:

What do you think of this?

---

But why would you need that?

The UID won't change, so a quick peek in heap peek is enough. It's a lot more efficient.

I have seen "UID to GObject Reference.vi" crash on some UIDs, so I don't like to use it loops, especially in production code.

[wiebe@CARYA]

---

wiebe@CARYA wrote:

---

@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.

---

Yes, this indeed doesn't work in PC executables.

[wiebe@CARYA]

---

wiebe@CARYA wrote:

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...

---

So here's a VI that returns variant data text in development and executables (Windows maybe Linux, not Mac).

The variant type text only works in development, it is ignored in an exe.

Based on Rolfk's VI...

[paul_a_cardinale]

---

wiebe@CARYA wrote:

---

wiebe@CARYA wrote:

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...

---

So here's a VI that returns variant data text in development and executables (Windows maybe Linux, not Mac).

The variant type text only works in development, it is ignored in an exe.

Based on Rolfk's VI...

---

It does work on a Mac.

[wiebe@CARYA]

---

@paul_a_cardinale wrote:

---

wiebe@CARYA wrote:

---

wiebe@CARYA wrote:

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...

---

So here's a VI that returns variant data text in development and executables (Windows maybe Linux, not Mac).

The variant type text only works in development, it is ignored in an exe.

Based on Rolfk's VI...

---

It does work on a Mac.

---

Executables too?

[paul_a_cardinale]

---

wiebe@CARYA wrote:

---

@paul_a_cardinale wrote:

---

wiebe@CARYA wrote:

---

wiebe@CARYA wrote:

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...

---

So here's a VI that returns variant data text in development and executables (Windows maybe Linux, not Mac).

The variant type text only works in development, it is ignored in an exe.

Based on Rolfk's VI...

---

It does work on a Mac.

---

Executables too?

---

Yes.

[paul_cardinale]

Should we add code to throw a warning if "Type (Dev. Only!) [F]" is True in a compiled app?

[wiebe@CARYA]

---

@paul_cardinale wrote:

Should we add code to throw a warning if "Type (Dev. Only!) [F]" is True in a compiled app?

---

I'll consider that when (iff) I actually start using the VI.

[1984]

So there are plenty of interesting comments, but frankly I'm kinda lost. It seems most of the comments focusing on getting the text out of a variant, but do we have a solution to that now? And even if so (data to string), is there a way to write the text back to a variant (string to data)?

[paul_a_cardinale]

---

@1984 wrote:

So there are plenty of interesting comments, but frankly I'm kinda lost. It seems most of the comments focusing on getting the text out of a variant, but do we have a solution to that now?

---

Yes.  It's "Variant Data To Text.vi"

---

And even if so (data to string), is there a way to write the text back to a variant (string to data)?

---

Why would you need to do that?  Just use the original data.