Wouter

But that goes against the reason for having a small compact VI i the first place

I never said that I was in favour for the small compact VI

But anyway I think I would rather like to see the icon stretched out a little then having the little gabs.

Maybe make the icon just as large as the normal clear icon...

What is exactly the functionality/use of the 'upstream error'?

Now with http://lavag.org/topic/14873-string-to-character-array-string-package/ this can be implemented?

Looks good JG. I think we have left one discussion... what kind of icon should the VI have? One that is fits between property nodes or the one we have now?

And I would change the label of "Error Code Matches" to "Error supressed?", I find the first terminology pretty vague namely.

This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI.

VI Name:

Supress error

Total VIs:

2

Description:

This VI has a integer (array), error code, as input and when the error code matches the error code on the error wire it supresses the error.

Note:

-

Blockdiagram:

Scalar:

Array:

Code:

Supress Error.zip

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• In which package should it be included?
  
• Should it be rejected?
  

True also convert the lower to double to avoid the coersion dot.

I'm in favour for such a VI.

Ok so this VI stays the same... then this maybe could be a candidate to cut a string into chunks.

Also when this ToCharacterArray VI is implemented then also http://lavag.org/topic/14875-shuffle-string/ could be implemented.

Well the reason Ton gave is a pretty strong one imo.

I think it should be added. It can be added easily to the current code. Just make the 1 constant a input variable and set 1 as a default.

Btw anyone any thoughts about the note in the OP?

Maybe there should be added another input with which you can tell that the string needs to be splitted every 2/3/4... chars instead of every char.

Should this VI be called "to Character Array" or "String to Character Array"?

If there is any interest in making the VI polymorphic, to accept other input data types, then "to Character Array" is preferable (I think). However, if it will only work on strings, it seems that it might make sense to make the name specific and go with "String to Character Array".

That said, are there any other input data types that we might want to support? I don't want to over-engineer this, but it's a question worth asking.

Maybe we want to be able to split numbers as well?

Like; input a integer 33747283; output a integer array [3,3,7,4,7,2,8,3].

But if this is very usefull I don't know. I never needed this in practice.

Maybe the code is faster when the check on length is done first. If 32 do check if chars are correct, otherwise return...

Maybe some more could be added aswell. I say

- AES, http://www.soslabvie...library-labview

- HillCipher, available also somewhere on the web

- CeasarCipher (easy)

- Blowfish

-edit- oh and the output of the md5 and SHA VI's have to be the same in my opinion. I believe the VI's of Ton have 3 different output formats.

Ya correct I forgot that first part.

Hmmm knew about the node but did not think of using it like that. But I'm sure that my version is faster. The rotation is O(n) while my function is O(1), proberbly it will not make that big difference but still. Further I like mine more because it is just 1 line, in a manner of speaking that the wire changes position (moves up)

True I was wondering about that topic as well... because I have a bunch of VI's for all kind of stuff, for example to calculate the Levenshtein distance or Jaro–Winkler distance but I can imagine that not every will need those VI's or want them on the pallet, but other people, like myself, may want them on the pallet...

VI Name:

IsOdd

Total VIs:

7

Description:

Checks if a number is odd (true) or even (false)

Note:

-

Blockdiagram:

Code:

Numeric IsOdd.zip

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• In which package should it be included?
  
• Should it be rejected?
  

VI Name:

Temperature conversion

Total VIs:

31

Description:

This VI converts a temperature to one of the existing temperature scalings. One could use the convert unit VI from the pallet. But firstly expression nodes prevent VI's from being inlined also it does not support all temperature scalings.

Note:

Blockdiagram:

-

Code:

Conversion temperature.zip

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• In which package should it be included?
  
• Should it be rejected?
  

VI Name:

String shuffle

Total VIs:

1

Description:

This VI shuffles a string.

Note:

-

Blockdiagram:

Code:

StrShuffle.zip

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• In which package should it be included?
  
• Should it be rejected?
  

VI Name:

String IsEmpty

Total VIs:

2

Description:

These VIs check if a string is empty and are alternatives to the existing one. I often find myself checking if 2 strings or more are empty to have a fast exit out of one of my string functions.

Note:

-

Blockdiagram:

Code:

StrIsEmpty.zip

What are you thoughts on this VI?

• Would you like to see such a function in OpenG?
  
• Can you optimize the code?
  
• In which package should it be included?
  
• Should it be rejected?
  

Currently I use it to split a string into chars and then randomize the array. Shortly put to shuffle a string. Further it can probably be used to spit a binary string to afterwards cast it to a integer. Further: http://www.dotnetperls.com/tochararray

Currently I use the VI with 2 inputs for a fast function exit when calculating the hamming distance of two strings. The array VI I meanly made because well... I can I'm sure there are probably more use-cases but I can't think of any of them now.