hooovahh

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.

Nope, as far as I know there is no way to programatically control this. There are a few private methods that have "Not Implemented" in them and mention Mercury and Merlot branches. This makes me think that at one point NI wanted this functionality, maybe for themselves but since it hasn't be finished in the several years that I've seen this private function I'd guess NI found another way to do what they wanted. If you have the source maybe you could make some hidden controls that VI Server can interact with but the user can't. Like if you have a File >> Exit function, just also have a hidden Exit button that can be invoked which triggers the same code execution. Of course this might be duplicating some of the work you already have. Another option for these menus might be keyboard simulation. If you press Alt+F it opens the File menu, then you could press Down arrow until the desired menu is selected. I've wanted this function off and on for a few years so I've made an idea exchange item here.

Sure thing, sorry I forgot a couple of other details. To enable VI Server access in an EXE you need to add a few lines of text to the built EXE INI file. In your case this is the Executable.ini file in the Executable folder. This INI gets rebuild every time a new build is made, so you will either want to edit this every time, edit it programatically using a Post Build VI, or you can actually specify the INI to use in the application builder settings under Advanced >> Use Custom Configuration File. In this case you can add this text manually just so you can see it working. server.tcp.enabled=True server.tcp.access="+localhost" server.tcp.port=3398 This enables the server, enables it for localhost access, and sets the port to 3398. This can be any number but needs to be unique. Then in the Open Application Reference you specify the port as 3398, and the machine as localhost. Once you have done this, run the EXE, run your VI, and you should be able to do things like list the Exported VIs, open references to those VIs, and get references to the controls on the front panel. Attached is a snippet back saved to 2014 that will read the Boolean Indicator value.

Will the steps mentioned also force LabVIEW to recognize the SO file as a dependency, and include it any builds? That's one issue I thought I remember having with Windows built EXE, when specifying the DLL path by the CLN input.

If you are using VIPM this is already done for you. To be able to install a package means that the VI Server business is already working. As for how to know what port is what version of LabVIEW, you can look at the LabVIEW.ini to see what port goes to which, and you can read the Windows registry to find what versions of LabVIEW are installed, and the path to the LabVIEW.exe and LabVIEW.ini files. This is all done in the source of the LabVIEW Tray Launcher I linked to earlier. Glad you were able to find a solution.

I literally shaved the day before. I can grow a mean beard, but I don't travel with any trimming equipment. So I shave on Sunday, and by Friday I'm looking pretty rough, and it's not just from all the Shiner Bocks. Also does everyone think they look dorky in pictures or is it just me?

The command line option only works if you know no other versions of LabVIEW are currently open. LabVIEW communicates over DDE to other versions of LabVIEW, and that is why some times you'll see LabVIEW try to open the wrong VI in the wrong version. If you double click a VI, or open it over the command line, it may choose to open it in the wrong version even if the command line specified which version to open it with. Here is a post I made on it a while ago and many other applications (like VIPM launching LabVIEW, and LabVIEW version selection tools) suffer from this issue. The work around is using the technique I've mentioned. But if you can ensure no versions of LabVIEW are running, maybe by closing them all, making a VI that runs when opened is much easier.

Well it is possible but a pain. Is there a minimum version of LabVIEW you want to support? I think that function came around in 8.2 or so. What I'd suggest doing is create a VI with just that function in it, and save it in the lowest version of LabVIEW you want to support. Then ensure each version of LabVIEW installed is configured to use VI Server from localhost (basically make sure VIPM can connect to each version). Then you can have a VI that opens a connection to each version of LabVIEW installed using the Open Application Reference function, then use the Open VI Reference passing in the path to the VI you saved earlier and using VI Server run it. I created a tool a while ago that sits in your system tray and allows you to launch any version of LabVIEW installed. It also allows you to abort all VIs running in all versions of LabVIEW and it uses this technique by having a VI saved in an older version of LabVIEW and embedded in another VI, and then runs this VI in every version of LabVIEW installed. The source for this can be found here with the topic on LAVA here.

Any improvements you can make are appreciated. I clearly don't know much about the web page side of things, I mostly was able to get done what I did with a lot of googling. Plenty of room for improvements, but I am using it on a real project and it meets my needs. As for the future of LabVIEW are you talking about the Tech Preview? http://www.ni.com/en-us/support/software-technology-preview.html WebVIs and porting the runtime engine to Java Script are things that have been announced, but the timelines mentioned (or not mentioned) makes me think it will be business as usual for a while longer. I'm not saying it isn't cool, and I'm not saying it isn't going to replace, or deprecate some of the work we are doing here, but I am saying you can use the code posted here today for free to create interactive webpages, and who knows when you'll be able to do the same with native NI technologies.

The "easy" solution as far as I know is the one already described, where you can place a transparent path control on top of your graph and set it to visible when your VI is not active (or mouse leaves the window, I'm not quite sure what works best). Then when you drop a file from explorer it will be dropped on the transparent path control, which generates the Value Change event, and from there you can get the path of the file dropped. It is not ideal, and if there isn't an idea on the Idea Exchange for this to be improved yet, I suggest making one, I'd vote for it. I wouldn't recommend using the Windows Queue API. With the advent of x64 versions of Windows several of those functions don't work, or will work most of the time, but won't work some times.

Set the front panel window to the window to hidden using the Invoke Node on the VI class (Front Panel >> Open - State). And in your built EXE you may need the HideRootWindow = TRUE in the INI of the application. My LabVIEW Tray Launcher uses this code to be minimized to the system tray, you can checkout the source here.

See I didn't realize this was a limitation. In my situation LabVIEW Libraries are the main container for code modules, not classes and this appears to be a limitation of LabVIEW classes which is why I've never seen this. So in my situation I can open both Windows Main, and RT Main VIs at once, and run them independently, or develop in either context with few issues (one being you need to sync code after making changes). Here is the article put out by NI (which was found in the idea exchange) that describes the issue with classes.

Why is this the case? If you have two different types of targets in your project, you have the code added to each target, and can open them independently right? I guess I haven't developed on two different RT systems at once so I don't know I just assumed it worked like the two targets I have in Windows and RT, although those have different top level VIs which might make the difference.

So it seems everyone here at least is passingly familiar with the issues I'm describing, but I wanted to document it a bit and I did this with some screen recording software. I also posted this on the NI thread that is partially discussing this: So last night I uninstalled all LabVIEW 2015 code, restarted several times, cleaned things up, and reinstalled 2015 and the RT module. Today I still have some recompiling issues when going back and forth. Here are two videos (because they are limited to 5 minutes using jing). The first shows opening a project, opening the Windows Main, showing the compile window, then opening the RT main showing the compile window, then resave everything, close the project and reopen. The second video shows re opening the Windows and RT main showing that files have to be recompiled yet again. Part 1 Part 2 So separate projects is the solution people are using? Man that seems like it could be a pain. I'm going to continue having it in one project for now. I have yet to see the brokenness but running issue. Seems like there are many issues with developing for multiple targets, and for RT in general. Honestly I'm surprised because like I said RT development has been a thing for around 10 years now.

So I decided to make a new thread on the dark side because this weirdness keeps getting weirder. It now does it on multiple versions of LabVIEW, and does it on the Place Palette Object On Cursor method.

Crosspost Honestly not sure which thread has more discussion. (BTW Shaun I gave you a like)

Nope, I stay logged in, Chrome 52.0.2743.116 (also Chrome is on version 52! Do they just increment it for the fun of it?)

Well this seems like a real issue, and one that people must have been struggling for for the past 10 years or so. Yes I am a big proponent of reuse, banging that reuse drum all I can. Which is partially why so much of my code is reused between targets, much of it resides in user.lib, or in libraries that are project specific but still reused between targets. The conditional disable diagram is used pretty often. Many templates used are the same between RT and windows targets, with slightly different things like timeouts and polling control values on RT, and disabling other fancy UI things when on RT. Some of the VIs that it shows having to recompile over and over do have conditional disable diagrams, but some don't, some are reuse, some aren't. Also last night I deleted my object cache, and reopened the project new. The issue still remains, that if I open the RT target some VIs need to recompile, and then if I close and reopen the Windows target those same VIs need to recompile again, but oddly the number of objects that recompiling is reduced down to only 22 VIs, making life a bit easier.

Is that a joke? Cause I like that.

The files I see it recompiling don't have a common theme other than the fact that they all seemed to be part of polymorphic VIs. I saw some from OpenG, which don't have the separate compiled code on, I have some from our reuse library which do have separate compiled code on, and I saw some that are unique to the project which happen to have separate compiled code on. I checked out my compiled cache file and it is almost 300MB, that feels a bit large so before I leave today I'll try deleting it, and having it rebuild for primary project I'm working on. Separate projects is an option for this design, but like you said I'm not sure it would fix my issue, and might actually cause some more. I do like how a project knows that I've been editing some code for one target and haven't synced my changes to the other. I'm not sure that would happen between different projects.

Examples like this are hard to give, since they often rely on multiple built EXEs, the right run time engine etc. But the basics of it, is you can use the Open Application Reference to open a session to LabVIEW, or a LabVIEW built EXE, if the settings and port are enabled in the INI file for LabVIEW or your application. Once this is open you can use the application reference to do stuff like list all VIs that are open in that application. From there you can use the Open VI Reference, using the application reference from earlier, and the VI name (or VI Path). Then you can use functions like the Traverse For GObjects to find objects in that VI that have the label and type you are looking for. There is also a function in the Hidden Gems package that can find object references by name. You can then cast these object references to their More Specific reference, and if that class type is a control you can use the property node Value Signaling event on that control reference giving it the data type associated with that control. Did I lose you yet? This is why I suggested editing your program to support the functionality you want, rather than try to augment it externally. Neither are easy, but one is more difficult than the other, and one is more susceptible to breaking if your code is updated, and your tool isn't.

So lets say I have a single project, and in it is two targets, a Windows host, and the RT. Many of the libraries I use in the Windows side, I also use on the RT side. But I think that this is causing lots of unnecessary "Compiling" of VIs over and over depending on which target I'm open the code from. Here's an example. I have a Windows Main.vi, and a RT Main.vi both under their appropriate targets. If I open the Windows Main.vi it opens relatively quickly, and loads about 2000 VIs and shows the main. But if I then open the RT Main.vi, it goes through and compiles about 200 of those VIs taking several minutes to open. So after both are open I perform a Save All, thinking whatever it needed to compile and do it should be done with. If I then close the project and re open it, and then open the Windows Main.vi it has to recompiles those 200 VIs presumably for the new target, and then if I open the RT Main it has to recompile those 200 VIs again. Is this how it is supposed to be? Every time I reopen a VI on a new target am I supposed to see it recompile for that target back and forth depending on where it was opened last? The project has a mix of VIs that have separate compiled code on and some with it off. Not sure which is better for this. My computer is relatively powerful, but lately doing LabVIEW development makes me feel like I'm using a 10 year old PC. Everything about my computer seems fast except LabVIEW development. Is there tips or tricks, or options I should be using to help make my LabVIEW development more responsive, and require less recompiling when switching targets? EDIT: It seems that the VIs that need to recompile all the time are VIs that are in a Polymorphic VI, so the majority of them are reuse and OpenG VIs. Double Edit: It seems this thread from an older post on LAVA claims that the compiled cache has separate entries for a VI on multiple targets, so I'm not sure why these VIs need to recompile every time...