Search 1D Array ... Changed in 2020 SP1

[jacemdom]

Attached video

[jacemdom]

---

@Jim_Kring wrote:

Here's a VI (attached) that will add Search 1D Array back to the Programming >>> Array palette programmatically.

Please take a look at the code to see if there's anything you recommend changing.

---

Please update to add the missing sort 1d array. Thanks.

[hollowhorse]

Ok, adding the sorted array search is an improvement of sorts, I get it.... But it's very naughty that NI removed such a staple function as the "search 1d array" and replaced it without any warning. Even ignoring the fact that the replacement VI has a confusing implementation for string data.

Come on NI - You're usually much better than this!

[MikaelH]

Darren,

What is the "path" for adding the "srt" into the menu?
For "s1d" it was: BUILT_IN_FUNC_1901_0_4_Function
How do we find/get this internal Build-In names of the build in functions in LV?

[Darren]

You can use the Read Palette VI to get this kind of information about palette items. When I use this to read the Array palette information from LabVIEW 2019, I find that the 'path' for the Sort 1D Array function is:

BUILT_IN_FUNC_1120_0_4_Function

...and now I'm realizing that the exact same issue that this thread identified with Search 1D Array is also present in LabVIEW 2020 SP1 with Sort 1D Array. I've brought it up with R&D to see how they want to address it.

[MikaelH]

Thanks, I'm happy again 🙂

[jacemdom]

---

@Jim_Kring wrote:

Here's a VI (attached) that will add Search 1D Array back to the Programming >>> Array palette programmatically.

Updated to add both sort and search 1d array

[Hooovahh]

<Code Comment>God helps functions that help themselves</Code Comment>

Glorious.

[Hooovahh]

---

@Darin.K wrote:

Seems risky to make a change like this (1) without warning (2) in a SP instead of major release and (3) without a beta test.  Had there been a beta, I would have easily fixed this for them.  Better late than never, drop this in as a replacement in <vi..lib>\Array\Search Unsorted 1D Array.vim  

I just added a dummy case to allow an element to be wired first.

---

I kudo'd you and thought it was the solution, until I realized it also allows for wiring an array of one data type, to a scalar of a different one, since it will select the dummy case as being unbroken.

I had a similar need for a VIM recently, and can't really figure out the best way to handle this down stream terminal changing without becoming an XNode.  Basically have unwired terminals become whatever makes it happy, but that would be a pretty weird thing to try to enforce.  For functions with an error terminal you could accept anything, and then have a runtime error, but that adds performance overhead, and partially defeats the purpose of a VIM. 

EDIT:  For VIMs with an error output I think the best solution for now is to have a type specialized case that if the data types don't match (Assertion Mismatch) have an error constant or error ring.  Yeah it sucks that you don't realize this is a problem until you run the VI and an error is generated, but honestly I feel like for most developers will know the data types need to match.  I don't know I'm conflicted.  What if the Enqueue function let you wire anything, but if it was the wrong data type it generated a runtime error?  Less than ideal for sure but I can't come up with a better solution at the moment.

[wiebe@CARYA]

I just tested my old "Template" XNode in LV20.

It basically does what an XNode does, but I called it a Template. I had plans to make a polymorphic-ish dialog to configure allowed input\output combinations, much like C++ templates.

I stopped developing it when I found out that class inputs and outputs crashed LabVIEW, but it seems the LV17SP1 fix fixed it for me too.

Of course NI could make this much better. I have to use the undocumented referrer functionality. The only documentation I know of is "don't use it".

Another issue was where to store the template information. In the XNode, or in the VI. Both aren't great options.