Leaderboard

​ ​Yes - fundamentally impossible from your perspective LabVIEW (or more specifically, G) isn't an interpreted language like Javascript or Python and it can evaluate the components of your expression in parallel, unlike procedural languages. So "b OR c" might be evaluated 10 hrs before "a" since an expression, or a component of an expression, is evaluated when the data is available, not when a program pointer steps to the next line.- that's dataflow for you ​

If you look at the link from Fab, you can see that you should probably use LocalAppDataFolder instead if you want the non-roaming version of it.

And here you walk into the mist! LabVIEW is written in C(++) for most of it, but it doesn't and has never created C code for the normal targets you and I are using it with. Before LabVIEW 2010 or so, it translated the code first into a directed graph and then from there directly into machine code. Since then it has a two layer approach. First it translates the diagram into DFIR (Dataflow Intermediate Representation) which is a more formalized version of a directed graph representation with additional features. Most of the algorithme optimization including things like dead code elimination, constant unfolding and many more things are done on this level. From there the data is passed to the open source llvm compiler engine which then generates the actual machine code representation. At no point is any intermediate C code involved, as C code is notorously inadequate for representing complex relationships in an easy to handle way. There is a C generator in LabVIEW that can translate a LabVIEW VI into some sort of C++ code. It was used for some of the early embedded toolkits such as for the AD Blackfin Toolkit, Windows Mobile Toolkit, and ARM Toolkit. But the generated code is pretty unreadable, and the solution proofed very hard to support in the long run. You can still buy the C Generator Addon from NI which gives you a license to use that generator but its price is pretty exorbitant and active support from NI is minimal. Except under the hood for the Touch Panel Module in combination with an embedded Visual C Express installation it is not used in any currently available product from NI AFAIK.

TDM? Is that a copy&paste-o? It points to the right target.

Delacor is thrilled to announce the release of the DQMH Toolkit 2.0 to the LabVIEW Tools Network (LVTN). This 2.0 release brings a number of new features (they are awesome and worth the download alone) and improvements. These changes were inspired by our desire to give you the best possible experience for rapid LabVIEW application development and by the great feedback we received from you. We have incorporated some of this feedback into our 2.0 release and will continue to do so on future releases. You can read the release notes for a full description of all of the changes. At your convenience head on over to the LabVIEW Tools Network and grab the DQMH Toolkit 2.0 directly or upgrade by refreshing the package list in VI Package Manager. If you are upgrading from an earlier version of the DQMH Toolkit please ensure that you upgrade the Delacor QMH package that will take care of upgrading all the toolkit required packages. All that remains is to launch the DQMH and get to work! Many thanks, Team Delacor

I am sure that a lot of you already knew what the "add property" button does in the installer build specification, but I am so happy about this discovery and I couldn't find anything online that I decided to share my excitement with my friends in LAVA. The application I am building works with a third party software that requires my installer to add things to the %appdata% folder, in Windows 8 this translates to C:Users<username>AppDataRoaming The default destinations available in the installer build specification in LabVIEW includes the [Public App Data] but in Windows 8 that points to C:ProgramData The help says that clicking on the Add property button under the Destination View lets you add a new MSI property to the Destination View tree. You can find a list of MSI properties here: http://msdn.microsoft.com/en-us/library/aa370905.aspx#component_location_properties and in particular there is one called AppDataFolder http://msdn.microsoft.com/en-us/library/aa367565(v=vs.85).aspx Well, adding the new property AppDataFolder was enough to set the destination for my ThirdPartyApp and the installer now successfully installs files in %appdata% folder. I hope this helps others in search of this information. Regards, Fab