Ton Plomp

You could set up a server using the Webservice functionality and connect to it with the HTTP protocol VIs. You even get security with that route. Ton

You can look at the labviewwiki entry for mercurial. I suppose a lot of the info is the same. Ton

And there are two API clients for LabVIEW (https://decibel.ni.com/content/groups/sweet-apps/blog/2012/10/22/never-pick-your-own-lottery-numbers-again#comment-24578). Full download at bitbucket Ton

LMGTFY: http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70 Ton

Have you tried debugging your app? You can connect your LabVIEW instance to the build executable (even on a different machine) and try to get a better detail of the errors. Ton

I have added feature request to the OpenG tracker for this functionality. Some detail on the code change is in this discussion. This review has the following options: Do not add a 'Maintain Phase' input Add a 'Maintain Phase' input, defaults to 'False' (means that we don't need to deprecate the old code) Add a 'Maintain Phase' input, defaults to 'True' (means that we need to deprecate the old code) Please add your vote (it's public voting), if you have input for this discussion please add it!

OK, I figured out what the essential difference between the two implementation is. The original OpenG Periodic trigger resets the phase upon every trigger. Your implementation is maintaining the phase. I have a little table showing this: Where I had a Time (ms) of 500 ms and waited 450, 100, 400, 100 and 10 ms. The column Next Trigger is showing the output state of the upper Shift Register which basically contains when the next rollover of the timer will happen. I think we should add both implementations, making yours the default for new VIs, the old functionality should be maintained via deprecation. So currently already code isn't changing current behaviour. Here's my proposal: And it's documentation: . Losing phase has functionality if you alter the 'Time to wait'. However we might need to auto-reset then as well. EDIT: Please note that you might get unexpected Triggers with Maintain Phase On: Ton

I am working on a Plugin system for the Code Capture Tool, and one of the plugins I have in mind is a 'LAVA Gallery upload'. Using some kind of authentication (user api-key or something) a user could upload codeshots to LAVA in a specific category. I have been digging around on the IP.Invsion page and there seems to little info on this. There is mention of an API but no documentation of the upload function (here) I allready added a feature request to IPS . But perhaps something like this is allready available. Ton

Perhaps there is a VI down there doing that (OpenG 'Size to contents'??). You can search for the text 'size' Ton

How do you make sure this will never run more than once a minute? (allright I have a simular one, that adds seconds, and I never make sure it runs just ones a second). Ton

So if I understand Stephen correctly one of the things witholding NI from forking the code from LAVAG (amongst others) is the BSD requirement to have the author in the license notes of a binary. I can understand the 'tight coupling' argument by Stephen (NI==LabVIEW). We could create a special version of the BSD that would remove the attribution requirement for binaries. It could be (for instance): This would be a 'Single Clause BSD' (see wikipedia for 2, 3 and 4 clause BSD's), we could even be more specific about where the license should be placed: Visible part of any FP Visible part of any BD In the VI/Class/Library properties I prefer the license in the VI properties, since it allows NI to use BD password protection (or even FP stripping) without breaking the license. EDIT: Now here's a thought/question for lawyers: If I put a license text inside the description of a class, will that cover all the VIs in the class? Shaun would it hurt to use such a '1-clause' license for certain products? Ton

I managed to get this working in a build application. Use a conditional case structure to load the NI Resource file in an executable: Place the Option VIs outside of the exe (otherwise I got an error 13) Place all of the dependencies inside of the executable (previous step would add a lot of files to the build result from within %resource%) You get the path by adding the VIs as a static VI members After those steps you can use the Preferences dialog in an executable. However it is slow. Really slow. And sometimes the framework will not load the data properly. Not sure why. However the timing (and complexity of the structure seems the culprit). Ton

So using a TimeStamp indicator instead of scan from string. I'm not sure if that is the intended use of a control. I would not rely on this trick/hack/gem. And I don't really see the need for that. Ton

The .orig files are YOUR files from before the merge: x.0----x.1------x.2 \----xa.1----/ x.orig is the x.1 file. Looking on Stackoverflow there are quite some posts about this file Ton

My advice: Put your .lvproj file in the root of your project folder (this sounds obvious), and has the following advantages: The default built location will be next to your project folder under builds (..\builds\project\buildname) That will most of the time prevent builds to get into your SCC Ton

For closing, you only need to close all the open Front Panels of an EXE, that will close the executable. And maybe we didn't understood your problem correctly. Ton

I never used it. The only instance I can see where it has some value is if you use a Non-Strict Typedef as a GUI element and you need to be in control of the UI. However if you are in that position you have made a poor decision. Ton