New Hidden Gems in LabVIEW 2018

[Darren]

The following hidden gems are new to LabVIEW 2018:

1. Sync.vim (located in vi.lib/utility)
   This .vim simply passes through two wire values. It can be used as a sync point on a diagram, where you want to ensure that data flow does not continue until the sources of those two wires execute.
2. 1D Array Sort VIMs (located in examples/Malleable VIs/Nested Malleable VIs)
   These aren't technically hidden gems since they are part of a shipping example. However, the functionality provided (notably the Sort 1D Array.vim, Search Unsorted 1D Array.vim, and Search Sorted 1D Array.vim) has been highly requested by the LabVIEW community and may become official features in a future LabVIEW release.

Note that for LabVIEW 2018, there is not a new Hidden Gems package on the Tools Network. Version 1.0.0.10 continues to be the latest version.

[PrimaryKey]

So many great examples of defining an interface for extending the inbuilt LV functionalities with your own algorithm details (lambda functions), defining object oriented types etc. yet nothing provided as a real interface, making it impossible to actually extend this and provide your own types. Why is it that smart steps in the right direction get hidden and buried? Why not just do it right once, and not these timid steps behind the scenes? These kind of features should have been in LV 10 years ago.

[BillMe]

Will these show up in Quick Drop in another release?

[Darren]

---

@BillMe wrote:

Will these show up in Quick Drop in another release?

---

I have not yet assessed whether there will be a new Hidden Gems package for the NIWeek 2019 release. I can say that LabVIEW 2019 includes a 'Synchronize Data Flow.vim' in the Synchronization palette that is an updated version of the Sync.vim hidden gem I mentioned above.

Also note that even if we do update the Hidden Gems package, we probably won't include palette entries for files in the examples folder.

[BertMcMahan]

I know this is an old thread but I just stumbled across Sync.vim (after making one of my own). Apologies if this is fixed in LV2019+; I'm still on 2018.

What's the purpose of the sequence structure frame here? Shouldn't the subVI boundary accomplish the same thing? Just wondering if there is a compiler optimization thing going on that I'm not seeing. My version just had a/a' and b/b' connected without anything else, and it behaves exactly the same.

[Darren]

As far as I know, the sequence structure is not necessary to accomplish the same task.

[James_McN]

Hey Bert,

I think it is because it is a malleable VI. These have to run inline which essentially removes the subVI boundary hence the sequence structure.

I've hit similar issues in the past where I inlined a VI but then the error line doesn't wait for the rest of the code to execute!

Cheers,

James

[Darren]

The flat sequence isn't necessary. The subVI boundary provides the synchronization, even with inline VIs. There should never have been a time where inlined VIs did not synchronize on the subVI boundary. James, if you can reproduce the issue, it should be filed as a bug report.