Leaderboard

It unlocks the file duh...but seriously I think the reason they named it that, is because in Windows if you download an EXE Windows security will prompt you with normal UAC stuff when you go to run it. But if you go to the properties of the file there is an "Unlock" button which is you telling Windows you trust the EXE. Still I think a different term would have helped understand what it does.

The cheap and dirty solution (my specialty) is a command line call to a function that does it for you. Here are a couple options. http://superuser.com/questions/94794/convert-a-mp3-to-wav-file-with-mplayer http://sourceforge.net/projects/snout/ https://quote.ucsd.edu/phonoloblog/2007/07/23/batch-convert-wav-to-mp3/ (this is Wav >> MP3 but I think it can be reversed) LAME Command line: "lame -V input.mp3 output.wav"

Where is this file located that you are trying to write to? I assume Program Files which Microsoft has said since Vista that area should be off limits for file writing. That being said most people still do it so it isn't such a big deal. My point is that you can choose to write files in a more secure (obscure) location that you will have write permissions on. Something like Application Data. If you do choose to leave the files in Program Files you can "Unlock" them during the install. This sets the permissions for you so any user can modify it. http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/build_installer/ Step 6.

Not quite what you are asking, but when I close a block diagram my habit is to use Ctrl + (EW) to close the VI completely ([save], Switch to front panel window, Close). Nothing special, but very useful for the purpose.

Agreed. You are much better of testing for an invalid refnum instead. Then it will be created on the first call and if it ever becomes invalid - recreated.

A minor warning about that technique. A reference is destroyed if the top-level VI under which it is created goes idle. The “First Call” primitive is reset when the subVI it is contained stops being reserved for execution. If you are working with multiple top-level VIs (such as if using dynamically “launched” VIs) then it is possible to invalidate the reference without resetting the first call.

It certainly doesn't work for an XControl in a VI that is inside a subpanel . In my particular case, I had a child window of the main application, which had a SubPanel, which in turn hosted a VI with an XControl. The Xcontrol had multiple panes and had a color ramp in one of them. Since a color ramp (z-scale) doesn't resize with panel (only the color box part does), I had to resize the color ramp height on pane resize. Now every time you resize any component in this chain, it produces a million pane resize events and you see the color ramp resizing animation for a while after you are done resizing. This issue made me search for the topic and I landed on this page. After failing to catch the "ending only" of the resize operation at the XControl level and the SubPanel, I have resorted to catching this event in the child window and then pass the message through the VI in the subpanel to the XControl. Not an elegant solution, but it works.

A bit of head scratching and some head banging later, I figured it out. The solution is quite simple actually. Lucky for us, the last event which occures after you the mouse is up, is registered and shows as being equal to previous. This will do exactly what I want. Some extra checking is required to trap maximize and restore sizes, but overall is a robust solution.