Unknown string when logging Variant to binary

[1984]

Now I'm back in the office and see that the solution I provided is really a no solution at all (as you said). I dont know what I was thinking... what I've done doesnt make sense at all. 

The set type info does solve the problem. Thanks!

UPDATE:

I'm totally confused now... the data(I32) returns 0

[altenbach]

---

@1984 wrote:

UPDATE:

I'm totally confused now... the data(I32) returns 0

---

How are we expected to troubleshoot what's actually in the variant by looking at a terminal picture of it? Can you attach some actual code instead?

[1984]

Its just the mod of what was attached earlier by raphschru, but here we go.

[raphschru]

My bad, I forgot that "Set Type Information" clears the data, like all VIs from the NI_DataType library.

So instead, you can use "Set Data Name" from the OpenG toolkit (Variant Data sub-palette):

[altenbach]

I still don't understand that gigantic detour via variant if a flattened string can represent the value of the data (apparently all you really want) with a fraction of the bytes, name or not.

[raphschru]

Sometimes you want to be very generic, so you need to have a variant that you can introspect using the data type functions, which is not possible when you only have the flattened value. But if you only need the value (and not the structure of the data type), I agree the flattened value is sufficient.

[1984]

---

@altenbach wrote:

I still don't understand that gigantic detour via variant if a flattened string can represent the value of the data (apparently all you really want) with a fraction of the bytes, name or not.

---

The tool I'd like to create should be able to log three data in one go: a timestamp, a string (which can be used later to identify the data) and the data. The data can be anything, so the part of the code taking care of the file operation should be able to receive any type of a data. So far I thought this only could be a variant (thats why the VIs I posted work with variants).

But now after some testing - and I'm a bit afraid of getting a conclusion after so many mistakes - it seems that flattening the data to a string is almost an instant operation, takes lot less time than working with variant. So maybe instead my logging VI having a variant input which can take any type of a data, I might want to have a string input and flatten the data outside of my logging VI. Does this make sense?

[altenbach]

---

@raphschru wrote:

Sometimes you want to be very generic, so you need to have a variant that you can introspect using the data type functions, which is not possible when you only have the flattened value. But if you only need the value (and not the structure of the data type), I agree the flattened value is sufficient.

---

It was said that the datatype information was encoded elsewhere. Variant to data or unflatten from string require exactly the same type input to get the variable data back.

Quotes from the OP:

> I'm logging a timestamp, a string and a variant to a binary file

>The string is a custom name for the data and it identifies the datatype when we need to check these logs.

I think the gist of this discussion was to avoid all the extra information (i.e. not related to "value") dragged along in the variant.

I would log a [cluster of a timestamp and two strings], then take the first string to identify how to unflatten the second string.