String to variant

[IbTkmk52]

Hello LabVIEW experts,

i want to convert a string to variant for a Property node which i use indipendent from the function. If i use the "to variant" function with an i32 as input, i am receiving the value which i need. But if I use a string as input it is converting it to the variant with the value "1" always. And the characters needed to be deleted from the variant. 

Also if i use the function Flattend string to variant i am receiving an error code. I searched in different forums but did not find an example for Flattened String to Variant.

The probe 3 returns the value without characters. I need this exactly with a string as input. I hope i was understandable.

Best regards

[GerdW]

Hi lb,

---

@IbTkmk52 wrote:

I need this exactly with a string as input. I hope i was understandable.

---

No, I don't understand your problem!

• A string is something different than an I32 value!
• They both result in different representations in the variant.
• FlattenToString also gives a different result than ToVariant.

So why do you to convert?

What is your source data?

What is the (expected) resulting data?

Can you provide exact examples? (Best is a VI with some constants or controls with default values!)

Your image is lacking the information about the data in your controls...

[IbTkmk52]

Hi @GerdW,

i attached a example vi. The main thing is that i need to convert a string value to a variant without charachters ("").

I explained it in the block diagram of the VI with a comment. Hopefully this will help.

[crossrulz]

---

@IbTkmk52 wrote:

The main thing is that i need to convert a string value to a variant without charachters ("").

---

You are storing an ASCII value to represent your number.  This is completely different than a "flattened string".  So you need to first use Decimal String To Number to convert to an I32 and then you can convert to a variant.

[GerdW]

Hi lb,

---

@IbTkmk52 wrote:

The main thing is that i need to convert a string value to a variant without charachters ("").

---

When you don't want those quotation marks inside the variant then you should NOT convert a string to a variant!

See this:

Why do you need a variant in the end?

What's the problem with quotation marks inside the variant display???

[IbTkmk52]

Hi Gerd, 

i am using the CANoe 17 Type Library to set a environment variable in CANoe. And the input of setting the value is a variant. Now in my case i have environment variables with the datatype of a uint32 or also a char. If i want to use the function i need to convert my string into a variant. That is the simple reason. 

If i convert the string first into a number than it will also not work for different characters like "HelloWorld", ... The input of the function (string) is a string not a decimal string. 

BR

[IbTkmk52]

Hi @crossrulz,

this would work if i use the string as a decimal string value. But the input can also be a character value, for e.g. "HelloWorld".

BR

[GerdW]

Hi lb,

---

@IbTkmk52 wrote:

this would work if i use the string as a decimal string value. But the input can also be a character value, for e.g. "HelloWorld".

---

The quotation marks are only shown inside the variant indicator, they aren't part of the actual data inside the variant...

What happens when you send a string to your CANoe tool?

[IbTkmk52]

Hi Gerd,

it is sending the value with the quotation marks and CANoe returns the value "1" back. So the TPL from ActiveXControl is sending the value also as a "1" with quotation marks.

[raphschru]

Hi IbTkmk52,

I think you are mislead by how the variant displays its value.

The quotation marks are only here to indicate that the value in between is a string.

They are not part of the value, these are just the variant's cosmetics.

---

@IbTkmk52 wrote:

it is sending the value with the quotation marks and CANoe returns the value "1" back. So the TPL from ActiveXControl is sending the value also as a "1" with quotation marks.

---

How do you know the returned value has quotation marks in its value? Did you convert your variant back to an actual string?

Regards,

Raphaël.