jgcode

:This shows that the primary input (the string) is not in the center of the Left hand Side of the Icon.

For programming style where this is in a wire, this gives odd layouts.

I don't think it's odd esp given the input and output are different datatypes.

I do agree it is not the standard comparison CP, but we have an additional argument input here.

Even if it was string in / string out if you check the first three String functions (top row) they don't match (offset vertically).

Here is an inline example.

Personally, I don't think this looks 100% right where the argument is - what do you guys think?

Also, it would helpful if you guys could post code of this VI with the CP's you want.

Cheers!

I think it should be consistent with the other comparison palette functions (in line).

I would suggest the Boolean 'strict' option be shown similar to other NI functions such as Array of Strings to Path and labeled 'strict case'.

(Sorry, I am unsure from your post) Are you suggesting you want it like Ton has requested (same as comparison palette) or like the Array if String to Path image?

I was going to suggest the same thing, but after years and years of working for managers who all have their own style (beauty is in the eye of the beholder) I was going to let it go.

Please don't (I did play around with inline too and other CP arrangements) - but this is the whole point of the review

Hi Jon,

As long as it's somewhere on the root palette, I'll be a happy camper

But, I don't think it should go on the VVariant palette, since that is for VIs that deal with variant data (at run time) inside of the variant inputs/outputs (at edit time). It makes sense if you think about it really hard, but is guaranteed to make your head hurt.

For example, in the snippet, below, you end up with a VVariant (a Variant containing a Variant containing a String).

Yes, sorry you are correct - it is a VData not VVariant output.

I will add it to the root palette, no dramas.

Cheers!

Hey Jon,

I'm not sure if putting it in the Type Descriptor subpalette is the best place (since this palette is for VIs that take Type Descriptors as inputs). I think that it probably makes sense to put it on the main, top-level palette.

Roger.

Unfortunately that spot is already taken

I will have to drop it down a row.

There is also a VVariant palette (which is what the output is)?

This is a very simple (wrapper) VI that would be a nice addition to the OpenG LabVIEW Data Library.

You can track this item here: ID 3411324

Here are the submission details:

Get Default Data from Variant.vi

TEST - Get Default Data from Variant.vi

Code is in LabVIEW 2009

It was a real headache relinking all the code that called those VIs - there doesn't seem to be a way to automatically find them in a new namespace. Very nearly rolled it all back

I am confident that the OpenG team will be able to solve this problem technically, without causing re-linking issues (with the help of a tool etc...).

If not, that would be a reason not to migrating IMHO.

...though I do now appreciate having the smaller libraries, as loading any one VI from a .lvlib loads the whole library. (If any does know how to do this, please tell me -- I'll feel silly for 5 minutes, then really appreciate it!).

It is my understanding that VIs are not loaded into memory, only the Library (.lvlib) is and any child Libraries.

If that child Library is a Class Library than yes, those Class method VIs will be loaded into memory as per the how Classes work.

Don't say I didn't tell you a way to make it faster.

lol... ok I won't however, your (s and Fab's) reply for code changes was what I was after.

I do however benchmark code using that setting, I found it to be the fairest and most consistent comparison. In completed code, I almost always find myself wanting to run subVIs standalone at some point.

Great tip, that should be noted as a valid use case of Subroutine Priority.

Personally I would not use subroutine priority in either case, I typically am satisfied with disabling debugging.

I like that an end used could easily read, follow or debug code, of course they could always switch this option back on.

Anyone else got a preference for this option - when to use it etc... (or bench marking) - feel free to start a new thread if needed.

Does anyone else have anything else to add - differing opinions etc...?

Or can I close this issue off?

Ok here is the updated candidate thanks to the improvements made by Darin and Fab.

Included in the ZIP is the benchmarking VI Darin mentions.

To Character Array.vi

To Character Array.zip

Code in LabVIEW 2009

Uhh... Coloring the label red then showing the caption instead kind of defeats the purpose of coloring it red in the first place doesn't it?

No - because the fact is you can change the caption without really thinking about it - but you haven't changed the label name which is the dependency (and hence your code is not broken)!

The BD label will still be red, and this is only for the case of a UI VI.

I love it!

I have the DETT installed on my system and only see the "Generate User-Defined Trace Event" under the palette "Desktop Execution Trace Toolkit" menu. I don't see any other VIs or an API that will allow for interaction with the DETT. Where are these other prims you are referring to located?

No, that is what I was referring to. Apologies.

You can track these bugs here:

• ID: 3411108 - Variant Configuration Library
  
• ID: 3411109 - LabVIEW Data Library
  

I think we have some cool code here, so this review is pending.

If there are no further comments in a few days I will close the review.

Thanks for everyone's input!

Personally, I would like to see this happen, for reasons listed in the OP (namely scope and namespacing) - but this is more from an OpenG Developer POV.

Additionally, I think it is inline with the way LabVIEW libraries are heading (or have been heading) too.

On a side note, I like the fact the VIs are just VIs for some of the ways I do building (tools etc...), but regardless I think .lvlibs are a positive move forward.

What are some of the End User benefits (or downfalls) of such a migration?

Please discuss - as I would like to see this topic advance.

PS What is Perce?

Parse I guess.

Security is the main one, so they cant change it but I can

Dan

FWIW, there is no difference writing ASCII using binary or text VIs (given you mentioned reading with config API):

It runs fine for me as well. I would recommend an uninstall/reinstall or repair of your RTE installation.

Yer, I had to format my entire HDD to get this fixed

Still didn't know what caused it - but on the upside LabVIEW ran faster

No, I was suggesting that functionality already exists in another product. I don't think the DETT has an API, so I am not sure how it could be a dependency.

Yes, it has prims you can drop onto your VIs from the palette (once you install the toolkit of course).

That's a good idea. (As long as the control isn't on the UI.)

Ha, I was going to explicitly write that...

But I don't think I have used that method on UI - and if I did, I would most likely send the data as e.g. a Class, and then update the UI accordingly using the 'API' of the UI

I like to do this (with Class) if I have a group of data to send.

OpenG Cryptography Library

Vargas has Crypto-G, other names I can think of are Encryption or Security.

But I think Cryptography is best.

Hey Guys, that's great!

On the topic of execution priority - I am not sure we want to this set as subroutine priority like we did with the Trim Whitespace change.

One of the reasons we did this was that NI's Trim Whitespace uses that setting:

I think this setting should be reserved for special cases only.

When do you use Subroutine priority? is a LAVA thread that Jim pointed me too.

Feel free to chime in there too with your experiences.

Of course please discuss in this thread if you think To Character Array should use this setting (highlighting pros and cons is helpful).

Hey Ton, having these functions in OpenG sounds like a great idea.

I (personally) think this VI is a good OpenG candidate.

Therefore I have OpenG'd the code and included a Test VI.

Please discuss.

I was unable to optimise the code further - can anyone make it faster?

To Character Array.vi

TEST - To Character Array.vi

Code is in LabVIEW 2009.

The code is developed by LV2010 Professional version. I want also to remind to everyone that the problem not apeare during the debugging but just when you compile the exe and you try to run it under a 2010 RTE.

Ok, I built the exe and it ran fine on my PC.

Do you want to upload an exe compiled on your PC too, and I will run it here just to check?

Aside from VI Shots (as you already mentioned) there is a HAL example here that might help (pdf + code).

Have you tried other PCs? - What is the result?

I have seen weirder stuff happen before.

Also, you could upload your code, so other devs can quickly build the spec and see if they get an error.