From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Search 1D Array ... Changed in 2020 SP1


@Darren wrote:

@Jim_Kring wrote:

 

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


Your VI looks fine to me. I assume if you build this into a VIPM package you'll have a post-uninstall VI that restores the backup .mnu file?


Thanks for taking a look at it. Yes, I was thinking that the package would restore the backup (original) .mnu file. Let me know if that all seems to work for you, and I'll get it packaged up.

0 Kudos
Message 11 of 44
(2,149 Views)

Yes, that sounds like a good plan to me.

Message 12 of 44
(2,148 Views)

I only have the old Search 1D Array. I don't seem to have the two .vims.

 

What am I missing? I do have LV20, with all the service packs.

0 Kudos
Message 13 of 44
(2,115 Views)

@Jim_Kring wrote:

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

 

Add to Palettes - Search 1D Array.png

 

It creates a backup of the original and it only adds it to the palette, if it's not already there. So, it should be pretty safe to run on even if someone accidentally runs it on something other than LabVIEW 2020 SP1.

 

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

 

If this is helpful, I'll probably end up creating a VI Package for this and publishing it on VIPM.io.


Hi Jim,

 

thanks for that VI, works like a charm !!!

 

Shame on NI for the poor change (nothing is mentioned in the change log of 2020 SP1) and the poor implementation (connect both input before the data type gets changed), and if you try to insert search 1D Array by quick drop, you get an error, although the abbreviation s1d is still known.

 

Regards, Jens

Kudos are welcome...
0 Kudos
Message 14 of 44
(2,105 Views)

wiebe@CARYA wrote:

I only have the old Search 1D Array. I don't seem to have the two .vims.

 

What am I missing? I do have LV20, with all the service packs.


It is a change that comes with LabVIEW 2020 SP1

Kudos are welcome...
Message 15 of 44
(2,103 Views)

@JensG69 wrote:

wiebe@CARYA wrote:

I only have the old Search 1D Array. I don't seem to have the two .vims.

 

What am I missing? I do have LV20, with all the service packs.


It is a change that comes with LabVIEW 2020 SP1


Ah, was looking at patch 1.

0 Kudos
Message 16 of 44
(2,100 Views)

All this professional focus on the positive attitude is certainly useful but not saying the obvious unpleasant truth is not.

 

I hope someone at NI finds the processes or procedures or people that created or allowed that giant monstrosity before it creates another one. 

 

This can surely be argued in many different ways and viewpoints, but the most important fact remains...

 

The search 1d array primitive is probably one of the most widely used primitives since forever and should never have been removed from the palette unless it was removed from the language!

 

I will continue my ranting a little to share my overall disappointment with LabVIEW in the last couple of years. I hope that ditching the obviously inferior development environment concept of LV NXG will give LabVIEW the much-needed support it needs! LV NXG should have been a rewrite of the actual LV concept and not a change of direction trying to fit LabVIEW into the currently popular textual languages IDE styles and workflows.

 

All this beginning to feel like apple after Steve Jobs...NI after Dr. James Truchard...

 

I hope NI never leaves the concept of all the VIs as independent modules, I use 6 monitors and LV NXG would never have allowed me to have the same amount of VI's opened and organized into code scopes on each monitor and sometimes subsections of monitors with diagram opened or not depending on needs and other documents. Personally, I wouldn't care that much if NI rewrote LV and broke the back compatibility, anyways if it was broken and became a big issue, I am sure someone somewhere would make a business out of it.

 

One hour lost…20 minutes due to NI and 40 minutes for my ranting…but…was it one hour lost…or one hour invested or one hour dedicated or one hour given…😅

Message 17 of 44
(2,000 Views)

Obviously when I say I wouldn't care if NI broke the backward compatibility to allow rewrites that would allow LabVIEW to grow better in the future, I don't mean a complete loss, but I would continue with LabVIEW even if 20% of my codebase was broken. And even more obviously, I would prefer only 1% break, but I would be ready to suffer a little if it allowed LabVIEW to evolve, after all LabVIEW as saved me from so many hours of suffering in textual languages that it's only fair to give some back 🙂

0 Kudos
Message 18 of 44
(1,997 Views)

@jacemdom wrote:

I hope someone at NI finds the processes or procedures or people that created or allowed that giant monstrosity before it creates another one. 


I haven't looked at it yet. What's bad about it?

 

I'd expect the code to be complicated. Like Sort 2D Array. That one is actually quite cleverly designed to avoid copies.

 

I'd think that the primitive wouldn't be replaced with a .vim if the .vim was less performant.

 


@jacemdom wrote:

Personally, I wouldn't care that much if NI rewrote LV and broke the back compatibility, 


I concur.

 

If the legacy code and features slow down progress, draw a line somewhere and ditch it.

0 Kudos
Message 19 of 44
(1,981 Views)

wiebe@CARYA wrote:


I haven't looked at it yet. What's bad about it?

 

I had a feeling that monstrosity was a bad choice of words. I am not talking about the code itself but the situation caused by removing the primitive from the palette. There is no logical argument for doing so. They still could have added the new vims and left it there. The vims are actually using it and at first glance looked like perfectly acceptable coding.

 

If they wanted to promote the usage of the new vims they just should have left it there and do the primitive will be deprecated in next version or was deprecated so stop using. The code already using the primitive should also have been modified automatically to use the new vims.

 

I lost 20 minutes trying to find out what was happening! First taught was my LV is corrupted so I went to check another installation. Then went back to LV 2019 to validate that I didn't dream that function for 20 years 😅

 

Then went at exact same place in the palette and saw the newly pink unsorted search vim...still wanted my old primitive...opened the code to find it...found it...went online to try and figure out what was that all about...found this thread...got emotional and wrote an editorial about it 😅

Message 20 of 44
(1,972 Views)