hooovahh

Well we can't control what window is active, the user can. I mean we can temporarily change what the active window is, but there is no telling what the user does. It could be a race condition between software and the user.

Your "final" looks cleaned up to me. Sure the terminals aren't quite right, and wires are a bit long, probably indicating that the terminals are added after the code generation (just a guess not sure XNodes actually do this). But you don't have wires on top of each other like the first image. Since this XNode lives in the VI that calls it, and is pretty much inlined as far as we can tell, the terminals are probably added when you right click the XNode to look at the generated code, and before then an interface to the XNode is this nebulous thing (at least to you and I).

So I just did a test and the GetActiveWindow returns the same HWND as the Front Panel >> Native Window, and the deprecated function Front Panel >> OS Window. Application >> Parent Window for Dialogs also returned 0 as mentioned earlier in this thread. I also thought you might want to know an alternate way of getting PIDs and the application names, so the attached VI does that too. EDIT: Oh and the command line program wmic can get some other PID information. Get HWND and PID.vi

Please don't post pictures. Would you take a picture of notepad and post it on a text based language forum? That being said the code you show is quite simple and all the work is being done in that one subVI which is where I'm guessing it is trying to read a file that it doesn't have permission for. Also that version of LabVIEW is probably from 2004 or so. Is that the current version your institution has? You're going to want to dig into that VI and probe around and see what is going on. Use probes, breakpoints, wires retain values (doesn't exist in LabVIEW 7.x) and the various step over/into, to figure out why this error is happening.

Awesome, you'll have a great time for sure.

So in my Find References XNode in my GenerateCode Ability VI, I call the Insert and Wire Template.vi which is a VI that I use for inserting a template VI (it still needs some work) but what you'll notice is at the end of that VI I have a constant set to false for cleaning up the BD. I just called the Block Diagram >> Clean up invoke node on the VI reference, which I got using the Owning VI reference on the Diagram reference passed in. I set that constant to false when I'm done, but have it be true during development so the code isn't complete crap and hard to debug.

Well a VI doesn't have to be reentrant to be dynamic. But generally this is what you want because dynamic usually means you are going to spawn N copies of this VI at once, and that can only happen with a reentrant VI. I'd start with proving it out on your host first. Here is a post I made a while ago showing how to launch reentrant VIs using a static VI reference and the VI name. This is a better way in most cases than using the VI path. http://forums.ni.com/t5/LabVIEW/building-an-executable-with-vits-with-Labview-2011/m-p/2384984#M740405 See how that works on the Windows development side. Then see if you can do something similar in a test VI on the RT. I haven't used the embedded UI but I didn't think there would be any strange limitation on the dynamic VI launching.

Bathtub Curve, could be early faulty hardware.

While we can't control google search results, I tired this. "Lava BBQ LabVIEW" https://www.google.com/webhp?q=lava%20bbq%20labview#safe=off&q=lava+bbq+labview And the first result was for the 2014 BBQ on the NI forums, where it has a link to the official announcement. http://lavag.org/bbq Which now directs to this page. Still I'd love me some of that steak.

Glad you found a solution. In the future post your code not pictures of your code. Things like history length on a chart is real easy to check when you have source code, but impossible to know from a picture.

Very catchy.

Okay you set up your hardware to sample at 1Khz, but then you choose to read it one sample at a time, so you hope to read a sample every ms. But you also need to do some thread swapping because every iteration you are using property nodes. Wouldn't it be better to say read n values at once, then wait however long you want, and read how every many samples there are to read? Change polymorphic type to one channel N samples. You're going to want to use a waveform graph as well, and keep the history your self. After you read N samples append them to the previous samples, then if the array size is too large, containing too much time, use array subeset to get the last N samples.

Restructure is good, but I'd suggest making the examples easier to find, maybe putting them at the top level. I just know when I get a new toolkit my first thing I do is run the example and see how it works and I had to go three folders deep to find the Example. Even if this is just a virtual folder in the library it might make finding examples easier. Personally I don't think requiring x64 Windows is that big of a deal but others might. I haven't used 32 bit Windows in several years. The only reason I see 32 bit LabVIEW used is because some toolkits aren't compatible.

Because recursion is fun, here is the link to the idea exchange to make this official. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Symbols-on-all-columns-of-a-multicolumn-listbox/idc-p/3161734

I admit I haven't been having a good morning, so sorry if I've been in an arguing mood. Not trying to be fan-boyish for Windows, just saying the tools that already exist for doing things in a semi-standard way, are the ones I will prefer to use. EXE versioning (in my opinion) should live with the EXE. It is convenient to store build numbers in this EXE as well. SCC should always (in my opinion) be used. It is convenient to have the build number in an EXE link to the SCC commit version. Times when EXEs aren't made, or when SCC isn't possible, then other options have to be used to track build information to the source it came from.

Okay point taken. But in this case I'd just make it clear that modifying source code without SCC is not recommended, which is true for all development. Currently the same way, and EXE is built for Windows, which includes the bit file needed for the FPGA, which links back to the commit version. EXE version 1.0.1.293 is commit 293 which is the master commit for the project which includes all source needed including FPGA. I guess the day that I have a project which has no Windows built EXE in it, I'll need to try something else, but again never has that been the case for me.

My customers have no interest in cross platform-ability. They do care for standardization, and they know how to find the version of an EXE without running it. They also know how to look up what version of the installer was installed by going to Add Remove Programs. If those don't match it throws up red flags for them. If my customer site doesn't have internet I bring along a 4G USB device with my laptop. That being said I haven't been to a customer site that didn't have internet in quite a while. Tracking what version of source was used in an EXE also tells you what version of the VI was used in that EXE. When coupled with SCC, this gives so much more history and diff management. I just see it as another thing to manage when SCC does it for you.

Yes it is possible to use tags that get read, or editing a constant on a block diagram. But at the end of the day I want my EXE to show the correct version, when you inspect it in Windows Explorer too. When you right click an EXE and go to Properties, then Details it shows the Product or File version. This is a standard way for applications to contain version information. Having a string constant on the BD that gets updated is just another way of showing a version which might not match. For this reason I'd really rather just maintain the version with the EXE, and then read that using the <vi.lib>\Platform\fileVersionInfo.llb\FileVersionInfo.vi The best semi-solution I have for this I posted here. http://forums.ni.com/t5/LabVIEW/Pre-Build-EXE-and-Installer-Set-Version/td-p/3149028 Basically it has a pre-build that sets the version, then makes sure any installers have the same version, then aborts the built, and instructs the user to perform the build again. This second build uses the new build information we just set. I tried invoking a new build but couldn't get the dialogs the way I wanted and it would sometimes show an error.

Are you aware this is a forum dedicated to discussions of advanced programming techniques using LabVIEW? OpenG is not the right subforum, and LAVA is probably not the right forum in general. This has been moved to the LAVA Lounge where any topic can be discussed.

Yes this works if the members you have in your library already exist on disk. Here you create the library, but you add members from disk. In my case I created an XNode which also created an unsaved member for State. State couldn't be saved because the library hadn't been saved yet, and the library couldn't be saved because State hadn't been saved yet. As I mentioned earlier this is similar to an XControl where controls and VIs are made simply by creating the XControl.

You can do this too. Capture Mouse Down? then use the coordinates and the invoke node to get the row and column clicked, then set the background color the the blueish color. LabVIEW can make software with any UI capabilities of any other programming language. It just might take some work arounds.

You can't do it the way you want. An array by definition means that every element in the array has the same properties, and only varies by value. This means each combo box needs to have the same drop down items. Now there are work arounds, like replacing the current items in a drop down with new ones as the user uses the control. So if I click on the second element I can change those items when it is clicked. I may have an example somewhere. It basically involves capturing the mouse down? event on the combo box then using that reference to set the items.

Hey my solution should work in RT, Windows, and Linux, with or without the IDE, inside or outside of an EXE, by passing in a VI reference. Just saying. (not certain about other platforms due to how the buffer is saved, but there are inputs to force it to Windows in which case I think it should work) But if NI improved those functions that would certainly be a better approach. Or if NI just saved the VI into a text file, or some kind of open standard, in which case looking for the block diagram using text would be trivial.

That's great if you already have an ability made and want to add it. It also doesn't do things like find the State control type def and replace them. It also doesn't set the allow run time. And you need to know the correct name of the Ability. But still you showed me one step that I could remove, which is when adding the file set the type to Ability VI.

The first post I made created the XNode and abilities using scripting. It would create the XNode, which is a library, then invoke the Add Ability where you specify the ability to add. Both the Create XNode, and the Add Ability don't work if you don't have a XNode license. Additionally List Members which usually tells you what items are in a library also doesn't work without a license. So I'm not sure what other scripting functions you could try from the project window. Just like with adding a VI to a project, you can't invoke a Create VI on a project using scripting. You first create the VI, then use the Add Item. And at this point we can't create the item, but we could probably add it if one was made. The only other hope I had was to see if the Project Provider Framework was used to implement the XNode creation in the project window. It wasn't, that would have been too easy. Just so I'm not completely defeated I figured I could at least post a XNode which has all the abilities on it for a version of LabVIEW. So if you want a 2013 XNode attached is one that has every ability. If you don't like the name, you can open the XNode in LabVIEW, and perform a rename which will resave all the members. That part does work without a license. To remove an Ability delete the VI, then open the XNode in a text editor, and remove the Item section for that ability. There are plenty of deprecated abilities that I probably should have included. Like how Build Menu has 4 older versions when you should probably just use the newest. XNode All Abilities 2013.zip