[CR] JSONtext

[Vortexhunter]

Thanks for that! It's what the machine is replying with, so I am stuck doing a string conversion after... 😒

[Jiri]

Hello,

I used JSONtext library in my old project and now I tried to brush this project and install this library through VIPM to Labview 2023 again ... There appeared an error concerning dependencies "VIPM couldn't download the package JDP Science Common Utilities v1.4.1.18 from the remote server ... Could you please check availability of this package?

Thanks

Jiri

 

[Jiri]

Hi

Already solved ....

Jiri

[Kjell-Edmund Ims]

The Reformat.vi function has a boolean input "Format empty string as null".

This input seems to be fully ignored as it happily continues to output "some_param":"" (empty string) instead of "some_param":null

 

 

[LogMAN]

In the context of this VI, "empty string" refers to the JSON terminal. If you don't provide any input, it will return null. Otherwise, it returns an error.

[drjdpowell]

I will change the terminal name to "Format empty input as null" to prevent reading it as referring to JSON Strings in the input rather than the entire LabVIEW string.   And I'l try and give a better description:

[X___]

When passing a "no error" error cluster to the "To JSON Text.vim" VI of the JSONtext toolkit, the output string is empty.

This is not the expected behavior.

I would expect:

  status = false
  code = 0
  source =

Tested with v1.9.1.125 in LV 2021 SP1 on Windows

[LogMAN]

This works as expected in version 1.7.0.118

Tested with LV2019 SP1 (32-bit)

{"status":false,"code":0,"source":""}

[drjdpowell]

Can you give an example VI showing the problem.  It seems to work in teh current source code.

[X___]

My apologies, I must have had a brain fart when I looked into that (I suspect isolating the vim from the VI I was using it and not connecting a "no error" constant to the input)?

Things work as they should upon checking again.

[barryc4]

Hi, I am using jsontext library in a project which I have been asked to localize to Chinese but get "??" out when using from jsontext.

Is there a way to do this that I am missing, or am I doing something fundamentally wrong. 

The dev PC in windows has all the localization / regions set to Chinese.
 

Thank you

Edited June 26, 2025 by barryc4

[drjdpowell]

JSON is always in UTF-8, and JSONtext will try and convert to your computer's character set automatically, so I don't think you need any of that stuff that has "UTF8".  Try simply using the single function to convert to a 2D array of strings.

However, by sure you are actually passing true JSON, with UTF8 encoding, not whatever your computer is using.  

[barryc4]

Thank you,

The issue was I was binding the string to a sqlite db as a "utf-8 string" then reading it as a "string", which is why it was causing it to fail.

I have made the execute sql vi read it as a single utf-8 which fixed it. 

[jmog]

Hi! Thanks for the awesome tool. I am seeing an issue that was reported also earlier in this thread (page 3), but I didn't see any further discussion about it.

The problem is 'To JSON Text.vim' not handling variant names, when converting from LabVIEW data type to JSON string. I am trying to convert a cluster that has some variant fields, but in the resulting JSON string the variant field names are empty. More over, if I have a variant as the first field in my cluster, the resulting JSON string is actually a JSON array instead of an object (which, according to documentation, should be the case, if the first field in the cluster is unnamed). To my understanding my variant fields do have names. Is this a bug or some mistake in my end?

Here are some snips from a test VI to demonstrate the issue.

     

[jmog]

Can't find a way to edit my previous post, so continuing here. After posting, I found the related discussion on page 7 of this thread. So apparently the variant names that get used in the resulting JSON string are not the name fields of the cluster, but rather the names of the pieces of data inside the variant. This feels very counterintuitive to me, but in case someone is running into the same issue, at least one solution is to name the data used inside the variant (see image below).

Would it be possible to use the names of the fields in the cluster instead of the names inside the variant? That would feel more intuitive to me and apparently several others as well.

     

[Rolf Kalbermatter]

19 minutes ago, jmog said:

Can't find a way to edit my previous post, so continuing here. After posting, I found the related discussion on page 7 of this thread. So apparently the variant names that get used in the resulting JSON string are not the name fields of the cluster, but rather the names of the pieces of data inside the variant. This feels very counterintuitive to me, but in case someone is running into the same issue, at least one solution is to name the data used inside the variant (see image below).

Would it be possible to use the names of the fields in the cluster instead of the names inside the variant? That would feel more intuitive to me and apparently several others as well.

     

Nothing is impossible but often so painful that not doing it is almost in every case the better option.

The label of the data in the variant is the label of the data element that was used to create the variant. The variant has also a label but that is one level higher. You could of course modify JSON to Text, but that is a lot of work. And I think it is up to James if he feels like this would be a justified effort. Personally I absolutely would understand if he feels like "Why bother".