hooovahh

Well there isn't a single solution. It sounds like what you want is a combination of tools, and will likely need something custom to meet your needs. It sounds like some of what you want can be understood with the VI Analyzer which is used to scan code for specific rule like no more than N local variables in a VI. There are several installed tests, and many extras online others have made. The code that runs these tests are in an LLB and you can probably copy it away and use it in your own scripting code. The project has several scripting functions, like getting all dependencies, and all dependencies that are of a specific type. (class, VI, etc). And the code complexity metric is an property node on a VI for Compiled.Code Complexity. I've used these tools in the past to generate pie charts showing how much code in a project comes from OpenG, or vi.lib or is written from scratch.

Without an XNode license creating a list of available properties and methods of the XNode and XNode Library classes is difficult. It is similar to having private methods. If you have a private property on the BD it works just fine and you can copy it and use it in other VIs. Luckily NI has scripting functions for doing things like setting property nodes and finding what properties are valid for a specific class. So with the help and collaboration with Jack Dunaway I've made a tool for getting the list of available property and invoke nodes for the XNode and XNode Library classes, and allow you to make those objects. Now not all of the functions will work without a XNode License but I suspect most do. Several abilities in an XNode return a XRef which is a reference to the XNode and is where these properties and methods could come in handy. Also attached is a VI that just has all of the properties and methods for LabVIEW 2013 SP1, but the tool should be able to make any new ones in newer versions as well. But all along we had the power to make these using native LabVIEW tools. Quick Drop has the class browser function, with it you can set the class of objects and the properties of property nodes. So following these steps will create an XNode property: Drop a new property node on the BD. Select the property node. Invoke QD Type "XNode" (without quotes) Press CTRL+B Select the property node Invoke QD Type "State" (without quotes) Press CTRL+Shift+B And lastly this is all very experimental. Using undocumented XNode technology, along with private functions can lead to unexpected crashing and strangeness. But for the most part these properties and methods have some level of documentation just don't be surprised if they don't work right, or don't do what you expect. Create Methods Properties for XNodes.vi All Methods and Properties.vi

The previous solution is probably better than mine, but I can think of an alternate way. Fonts are installed in Windows in the following path %windir%\fonts You can probably perform a list files finding all installed fonts there. I'm not sure if fonts can be installed into a location other than that, and if it can then that is a reason the .Net method might be preferred.

Obligatory free training links. NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Self Paced training beginner to advanced, SSP Required LabVIEW Wiki on Training

I just tested the progress bar and it doesn't work for me. On Windows 7 x64 LabVIEW 2014 SP1 32-bit, the progress window comes up, but the progress bar doesn't move forward. And closing the dialog hangs LabVIEW. I looked into it and for me an error is generated in the Get ProcessIDsOfWindows.vi, and the while loop never stops executing. It should probably stop on error.

Wow really? I haven't had a chance to try it yet but I sorta agree with Shaun, even though this is a feature I could see myself using. Lots of cool features in this but we need some stability. I mean the structure and file layout alone has changed probably 3 or 4 times since discussions started. And the code could still use some much needed attention in the form of interface, icons, and documentation.

You already have it, launch the example finder Help >> Find Examples and search.

LabVIEW 2015 leaked screenshots via Hollywood movie? Probably not.

The previous link seems to do just that, it measures the time it takes for a loop to iterate. But in most situations I'd recommend instead of trying to capture each frame as it comes in, tell it to acquire at 30FPS but then ask to read the frames remaining in the buffer. This way if your loop rate is 200ms that's fine, you'll still get all the frames. There are examples shipped with IMAQ that demonstrate both methods, and even shipped examples to calculate the actual FPS and time between iterations.

Okay deep breathes everyone (including myself). New users need to be pointed in the right direction some times, there were times when we all knew nothing so they should have some slack just like we should have had some when we were new. But on the other side of it, how are new users going to know proper etiquette if we don't point out what it should be? Lets try to be mindful of other cultures and remember we all have bad days. Lets just try not to take it out on others. We can be overbearing at times, and new users can make mistakes.

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.