Leaderboard

Ahh. But to call yourself a LV Architect you do. They even have special orgies every year that no mere mortals, however capable, can join in. They speak in tongues and discuss spells and other voodoo magic that no non-architect can understand or even hear without going insane. Then they go back to their local covens to plan the next act of debauchery with the new curses and sigils they have learnt. Well. Read it now It looks like an ActiveX driver so there's the problem in a nutshell. If it wasn't for that, I expect Gerd would have not needed as much patience (but you are right, he is a saint)

Name: Find References XNode Submitter: hooovahh Submitted: 03 Feb 2015 Category: XNodes LabVIEW Version: 2012License Type: BSD (Most common) Description This zip contains an XNode which makes finding references to objects easier. The core of the attached XNode is a modified version of the Find References by Label VI that can be found in the vi.lib. This VI will return the first match of a control that has the label provided. This modified version has the ability to find all references that match a label given a string which the label contains, starts with, ends with, or it can be an exact string. So for instance it can find all objects that start with "Numeric". This XNode still has the ability to return a single scalar reference like the original, which can be done by right clicking the XNode and un-selecting "Find All References". By default it returns an array of references found. If multiple references are chosen, the order of those references can be changed. An enum is used to change the sort method from String Sort, Numeric Sort, Sort from Left to Right, Sort from Top to Bottom, or Sort from Top to Bottom then Left to Right. This is most useful when you have controls on a front panel arranged in a grid. Another improvement over the native function, is the output reference type is changed to a selected class. Right click the XNode and go to Select VI Server Class to select an object type. There is also a browse button which brings up a dialog where the list can be alphabetized, and a simple string can help find the type desired. Other features of the native function are still provided like using caption labels on controls, and searching the front panel, block diagram, or other owning reference types. Demonstration Below is a video showing the basic operation of the XNode. It demonstrates how to find control references, and how the sort, and search features work. It then shows that the same technique can be used to find any object type on the block diagram too. http://screencast.com/t/gFBen503rg XNode Disclaimer NI does not provide support XNode development. It is an experimental technology and neither I, nor NI can be held accountable for unexpected operation. For an introduction to XNodes read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint). Dependencies OpenG Error Library-4.2.0.23 OpenG Array Library-4.1.1.14 OpenG String Library-4.1.0.12 OpenG LabVIEW Data Library-4.2.0.21 Click here to download this file

Oh you just had to ask didn't you. Well I was going to reply without trying it cause I assumed it would work...turns out it doesn't. It doesn't take much to make it work. You have to modify the Search Filter 1D Array of String to return the item as always matching, if the search string is empty. I'll look into adding this to the next version. EDIT: Another advantage of this is then the label input can be optional.

Actually the 64 Windows version is not the real problem. Haven't tested all but it compiles. What is the challenge is the various Linux variants at the moment.

LabVIEW already supports 64-bit (File IO>>Zip). If you are after the OpenG stuff, it's all going on here.

Damn. I've been posting on the wrong forum all these years. I'm neither an architect, nor virtual although I am advanced in years .

LabVIEW does not expose an interface that would allow to load .Net assemblies dynamically. It is actually even so that any .Net assembly that was at some point loaded, will be kept loaded which can be troublesome if you want to debug a self written assembly and try to replace the previous assembly with a new one without restarting LabVIEW. Therefore your best bet is to create a .Net wrapper assembly that implements your plugin interface with one additional method Initialize() or similar that takes a path to the actual .Net assembly and object instantiation you want to use. Then load that assembly in that method and instantiate the object interface you want and store the object pointer in a private variable. All the other methods and property accessors of your wrapper simply forward their call to the actual implementation in the initialized assembly object.

What happens? Sounds like a bug that needs squashing. NI would do well to accept contributions from the community!

Multi-platform binaries are far from trivial. LabVIEW makes cross platform development a breeze, but to create binaries for it to use is still very resource intensive especially as they have just added Linux and Mac 64 bit support in LV2014. That equates to a minimum of 8 different binary builds that must be created, maintained and tested on multiple operating systems, multiple hardware targets and multiple LabVIEW versions and lets not forget build tools, scripts and 3rd party stuff. Testing and debugging alone is a full time job in reality and Rolf has a life and paying work to factor in too. The good news is that once it is done. That should be it for a few years

I'm not going to make any promises here. But I'm working on it and tackled one more problem this weekend. As it seems it is now mostly some more testing for the Linux/VxWorks version and then wrapping everything up in an OpenG package. I might post a prerelease package here for testing and review and certainly will need some assistance in getting the final package uploaded to the VI network somehow.