hooovahh

So do you still use the 8.x layout on all applications built? I haven't used the 8.x layout since 8.6, and yes I do believe the only real benefit comes from when you have two VIs with the same name in different libraries, it isn't necessarily a LVOOP thing. There maybe other benefits that NI has made into compiler optimizations that maybe only effect newer layouts, but only NI could say for sure. I may have a library that reads an analog signal on one piece of hardware and so to organize it I name the VI Hardware X.lvlib:Read Analog.vi I can then have another library with another name Hardware Y.lvlib:Read Analog.vi Having two VIs named Hardware X.lvlib:Read Hardware X Analog.vi and Hardware Y.lvlib:Read Hardware Y Analog.vi seems unnecessary when the library name already states what hardware it is for . As you are probably aware the flat layout of 8.x means they can't be in the same folder so more folders are made to fix this, where in the newer layout folders exist and so these VIs can reside in the EXE with the same folder structure as on disk.

This thread is 7 years old, and predates several LAVA database issues and data loss. I wouldn't expect to be able to find the original attachment, and those involved in this thread likely don't have a copy of the files.

I've used the Variant Probe as a probe (in the development environment) but also used it on the front panel of a VI, and in a VI that is built into an EXE without any issues. I used it in debugging messaging data between parallel actors in the EXE, so I could see a history of the messages that were send and received, and the data in the messages. It wasn't used too often, but made it possible to get an understanding of what the individual actors were sending, and thereby what they were doing without a full development environment.

I try to never miss out on an opportunity to toot Ton's horn when it comes to that XControl. Yes as already mentioned the Variant Repository that is available for download here is a VIPC, which contains the Variant Repository, and the Variant Probe. I included it because I felt that XControl really is a simple way to view variant data and it's structure, which is why it was included as an example showing how Variant Repositories work. When I give my XNode presentation, I start by explaining how they are related to XControls, and I use the Variant Probe as the example XControl. It's a perfect XControl, it's use cases are relatively small, you don't have lots of weird user interactions to worry about, and it displays data in a way on the UI that is more clear than any other native control. But do be aware that there is a bug with the Variant Probe, and updating it often in a loop will cause a very slow memory leak which will cause LabVIEW to take a longer than expected time to close. I reported the bug here but no new package has been made, so I just posted an update with the fix in the package.

I just realized this bug still exists and no update has been made. So for others that might be interested in using this with this fix applied, I made the fix and rebuilt the package. The spec has the version limited to >=2011 but I can't honestly remember what version I saved the VIs in and I only have 2015 installed at the moment. Variant_Probe-2.4.2-0.ogp

Through scripting? Looking at the available classes I think your only option is going to be to save a VI somewhere that has the register event callbacks configured the way you want, then programatically copy and paste them in. The reason I suggest this is because the Register Event Callback node appears as to be in the GrowableFunction class, and that has no methods (private or public) that can set the method of it. So the only solution I can think of is to make a VI that you'll use as a template, and it can have all the nodes configured the way you want and just sitting on the BD.

We have some 3rd party software that generates Access databases. For those I use NI's database connectivity toolkit. It was the first I tried, it was free (or included) and it worked. But for new database my software creates, I generate them and read them using SQLite and your toolkit. We don't do much database work, and it has always been decentralized.

You can still perform a Find All Instances of a particular VI, which is probably more useful because you will only find the VI for a particular method call of a FGV, instead of finding every instance. I believe what you are asking is if you can search for the polymorphic VI, to which I believe the answer is no, you can only search for members of the polymorphic VI, which in this case would be a particular method.

Yes this was already posted in LAVA over here in the LabVIEW >> General section, but to be honest I think this is more appropriate in the Lounge so I'll leave this here rather than merging it.

Yeah I like this idea and made a (half complete) tool for generating these polymorphic VIs from FGV, posted over here.

So here is the VI I've been using, I can't remember where I got it from but I believe it was on NI's community page. The account I've been using has the less secure apps enabled and that's it. It is using port 587. Is it a network issue on your end? Does it work from another network like at home? Email Using Gmail.vi

Sure, there's a couple of options but I think what can be done is to on startup, get all control references, then find which ones are type defs, and then get the path to those type defs, and if the path is what you expect, to register for those control references. Attached is a demo. Find Type Def Demo.zip

I was always cautious when using the aggregate compare mode because I didn't fully understand what it meant. Reading through the documentation it seems it should work the way you described.

Does it behave this way on other computers? Maybe resetting MAX config? Not quite sure really but if you tried another piece of hardware and it behaves the same it would make me think it is not the hardware, but some software or config on that PC. What kind of scale is used? Is it a linear, table, mapped range, etc? I guess it probably doesn't matter but I'd try to see if I can make any scale work on the full range.

A quick google search shows several tools for removing passwords from zips. No idea if these actually work. Alternatively there are tools like this one which appear to brute force the password for you. http://www.isunshare.com/blog/how-to-remove-password-from-zip-file/

"This contract engineer discovered the secret to LabVIEW programming, and NI is furious."

To answer the primary question of the thread, yes I do still use them but kinda rarely. For each medium to large sized project I'd say I probably create 2, and there are probably another 3 or 4 buried in reuse library function, used in the project. The reuse functions I can make a decent argument to make them classes, for the project specific ones, I could say the simplicity, and ease of use for other developers makes me want to leave them alone. In most of my cases I don't see action engines working well because there maybe a time when I intend on doing some kind of periodic function, like checking status and reporting it every 100ms, and an action engine is a blocking, synchronous call. So I usually end up making a separate asynchronous module (actor) so that in the future if I need to do some task periodically it can be done there. The calls to this will still look like the action engine, but with a message to the actor, and then a message that is in the reply coming back so the call will still be synchronous, but asynchronous tasks can take place too. It's rare that I can convince myself that an interaction with some private data, will never need this feature.

Yup totally agree. Array stuff needs to be evaluated. Many improvements could be made from inlining, to the new conditional, and concatenating terminals in 2012. Several things could be removed from the palette too to use the native functions if they have replacing functionality. Things like Strip File Extension exist on the File I/O palette, but don't quite cover all of the same functions. Same with some functions on the LabVIEW Data palette, and the newer variant palette.

The LabVIEW compiler is smart, and it knows that if you are doing some operation that doesn't use the outputs (and a few other key determinators) then it won't even execute the code at all. Your case 11 isn't actually being executed. This is dead code elimination and constant folding. Updating controls is an asynchronous process, and adds a lot of jitter to measuring timing like this. That's one reason why you'll notice my code doesn't update any of the controls until after all timing values have been taken. To get a more accurate measurement you should not update or read from any control terminals inside the sequence structure. I highly recommend watching some of these NI Week videos from this last NI Week where Ed and Christian talk about performance measuring and benchmarking. https://decibel.ni.com/content/docs/DOC-48493

You are a braver man than I. I wouldn't go through the registration, I'd be concerned NI was going to charge me for an event that took place in the past. Thanks for being your guinea pig.

Because you're doing all the operations in parallel, this is a poor test and should be only doing one thing at a time. Also you should disable debugging, and automatic error handling. I also think your time is too small to measure well enough. Maybe try a larger sample size. Here is a speed test I did on the writing of the new IPE and it shows improvements. https://forums.ni.com/t5/LabVIEW/Correct-way-of-using-the-Variant-Get-Replace-In-Place-Element/m-p/3334502#M978560

I think 20%-25% might be over estimating it a bit. 9% XP, 1% Vista, and sure 50% Windows 7, but if they are connected to the internet it should be SP1. But it's hard to say, especially in the test system fields, where older machines are more common than consumer devices, and being isolated from the internet is more common than a consumer PC. Still I consider myself up on the latest updates of NI and LabVIEW and this was the first I'd heard about it. "Not being clear and upfront" is an understatement. BTW that's a neat site.

Sensational title much? It still supports Windows 7 SP1, I've built EXE in LabVIEW 2016 32-bit on Windows 7 SP1 x64 without any issue. I've also built applications in LabVIEW 2015 SP1 32-bit, that have 16.0 dependency drivers, and that builds and deploys to Windows 7 SP1 x64 without any issue. As mentioned in that thread dropping OS support should be made more obvious, but this is really Windows 7 SP0 and older that official support is dropped for.

Okay here's the solution I did that seems to work. You need to make the window the front and focused so that the key presses go into that window. This can be done by setting the Z order. Using this API there is a function called Move Window To Top and you just need to give it the window title name. http://www.ni.com/example/29935/en/ Then I used a this API for sending key presses like Alt and then arrow keys (with delays in between) https://decibel.ni.com/content/docs/DOC-15310

Because the XNode features of LabVIEW require a special license by NI, these properties and methods won't be listed on the XNode, or XNode Library class, but these functions do work. I made a post about this a while ago, and showed how to create these functions in vanilla LabVIEW if you use scripting, or use the QuickDrop function and know the name of the property or method you want. The code I posted also can create a new VI, or place the hidden property or method in your clipboard. I also posted a VI with all the properties and methods that scripting can make which you can use and copy into a VI and use.