Darin

I have run across whacky users who do things like delete .ini files. What I have taken to doing is not installing the .ini file but recreating the default one within the program when it can not find one. This can be as simple as keeping the default ini file inside a string constant, or if I have a configuration page I just save the default configuration as if the user had changed nothing from the default values. Along these lines, I can also detect an ini file from a previous version. In this case I can provide mutation code to update some values, and toss others. I do this inside the app, interesting thought to make it part of the installer, but I guess you only have one shot at mutation that way. Again I have seen (and perpetrated) copying of an old ini file after installing an app, and that is why I chose to make it part of the app. NI does something like this to you (each year a new version with a new ini file). How do you like it? I usually copy and hope nothing blows up.

That is the method that is shown in Darren's VI and that Yair suggested. Although the image is scaled so the effect is reduced in your case, you can still see that the interior lines are double thickness.

There is a lot of funny business going on with the terminal bounds and with the Draw Rectangle vi. On the surface, it appears the TermBnds[] property is wrong because it returns value between 0,0 and 32,32 which means a size of 33x33. However, Draw Rectangle does not really use the values of right and bottom, it actually gives rectangles with the width and height specified (for line width = 1). For example, if you draw the rectangle from (0,0) to (8,8) and look at the 1-bit pixmap you will see that the pixel indices are 0,0 to 7,7. When you turn around and draw a second rectangle from (8,0) to (16,8) you get a second line at column 8 in the 1-bit pixmap, ie. a double-width line. What a mess. An easy "fix" is to compensate by adding 1 to the right and bottom values. Now you get a nice conpane outline with all single pixel lines. The only problem is that it is now 33x33 pixels (if you care).

Should have been an obvious assumption on my part that you were changing the name. If you remember the funny business with the 'HideRootWindow' ini key and multiple entries in the taskbar, this issue is almost certainly related to that. At any rate, an executable appears multiple times in the windows list. The name of the first entry (numerical order) is the window title. The other two entries have the name of the executable without the extension. The proper handle happens to be the second one in the list. When you change the window title to match the name of the executable without the extension 'CloseMe' in this case, then FindWindow will now return the handle to the first window instead of the second. Now you are pumping messages to the wrong one and havoc ensues. Change the title to 'Change Me' and still use 'ChangeMe' to find the Handle and you are all set. My personal naming convention combined with the very small number of times I have pumped messages to executables has kept me safe from this behavior. When naming files I leave out spaces, but in the window titles I use them. I'd rather be lucky than good.

Here is a barebones example. You can build the exe from the project, or run the included one called CloseMe.exe. You can run Pump WM_CLOSE.vi to send that message to the running executable, if the popup appears then the Event Fired. Test WM_CLOSE.zip

The simple answer is that the 'correct' way to handle this message is indeed with the Application Instance Close? event. I can pump this message directly to a LV executable and it fires the event every time (so far). There is a bit of a goof in your top image, the code for WM_CLOSE is 0x10 or 16, either change the radix of your Case Structure (yes) or change the value. Unless for some reason you have registered and are looking for WM_ENABLE. Is this an intermittent problem? By that I especially mean does it happen to some executables all of the time, all executables some of the time, or some executables some of the time? And how exactly are you triggering the shutdown that fails to kill the process? Perhaps it is not sending the message you expect. Of course while testing I notice several Chrome processes running on my machine with the browser closed so perhaps it is not so uncommon.

Now I understand the pricing, there is "extra" pride in the 12 month membership.

I usually stick with the Pane Size events, I believe that those will fire as expected in the subPanel.

Did you invoke the Inline method?

I usually create a new subvi on the diagram using a path to the template. SubVIs then have a method to place their contents. I am on my phone so this is from memory.

The easiest way would be to use the Riffle VI in LV, but up until LV12 it is biased since they botched it. I would grab my replacement which is in this thread: http://forums.ni.com/t5/LabVIEW/Riffle-is-Biased/td-p/1921103 You can initialize an array to the correct size (no need to worry about the values, they can all be zero), then Riffle the array and use the index output. Or it is pretty easy to specialize the VI to simply produce the indices without the dummy array.

I have a quick and probably very dirty test that I use (I really hate seeing code with a bazillion close references on there). I will Type Cast the reference to an unisigned integer. VIs, Projects and the like give you a different value each time you run, those references I close. Others, such as controls and panels give the same value each time, those I do not close. Works for me so far. Also, it is shown in a picture, but it should be spelled out more explicitly that Close Reference does in fact accept arrays (why not clusters?) which can clean up a lot of code. Probably worth mentioning one other rule I try to follow at all times in subVIs: If you didn't open it, don't close it.

1. Substitute html or pdf for chm and I like this option. Easy to have the file local, on the corporate network (one place to fix errors), or anywhere. There are much better tools, references and examples for dealing with html as opposed to chm. 2. In moderation, I am usually a bit inpatient with these. They seem to hide when I want them and show up in time to block what I really want. I do not need to know that the button with the stop sign picture is 'stop'. What I really like is when you have a status bar on the bottom of the window and just pop the would-be tip strip string into it. Context Help: It is probably just me, but I find that a bit klunky for an application. Works well for the BD, but it is growing,shrinking and otherwise distracting. It is easy to learn to love it when you are the developer in charge of reinventing that wheel, but users who do not know or care about the trouble involved may not like it. (Caveat, I am too spoiled by what I can do in other application frameworks, things like balloon popups with html formatting). I have a pile of Kudos on a different forum because that is a patently false statement.

I'd hold off on that one until he learns the proper capitalization. This would be a no-brainer.

From the VI description of the first random file I opened. © Ton Plomp, 2011 THIS SOFTWARE IS PROVIDED AS IS, AND ANY WARRANTY IS REJECTED

For some strange reason I was getting compile errors yesterday for all of my attempts to parallelize loops with conditional indexing. Perhaps playing with timestamps was a problem. A few reboots later and today I can actually get it to work in my benchmarking code. Good news: On my dual-core machine I can get about 6% improvement by enabling parallelism. Bad news: That still leaves it 4x slower than the standard replace+trim method. It seems a bit finicky, but if the bugs are fixed then I will retract my comment and say let them stay. No Panacea, and it is yet to be determined if the modest boost is maintained if the code is optimized. Virtual beer (real if I ever make to NI week) when the concurrent filter reduction significantly beats the optimized single thread version.

The fix is simple, conditional tunnels should not be allowed in a parallel for loop, build the code in the conventional manner to see why. The compiler figures it out the hard way, but the IDE should not allow this.

That gives me a new idea, perhaps there should be an option to throw an error (or warning) if a coercion takes place. Now if only there was some way to let NI know I had this idea....

Thanks for the plug. I can offer a few thoughts: Like most things, I think the Idea Exchange has stages: 1. The IE is going to revolutionize LV. 2. The IE is going to transform LV. 3. The IE is going to alter LV. 4. The IE is going to change LV. 5. The IE is going to have an effect on LV. 6. The IE is going to have a small effect on LV. 7. The IE is going to have no effect on LV. I think we are headed down the list but I won't publicize where I think we are now. As to the Kudos weighting I can offer the old parable about the pious man on his deathbed who kept praying to win the lottery. Finally after a few weeks pass and he hasn't won, he questions his faith and asks God "Why have you foresaken me?" At that point God asks "Could you at least help me out by buying a lottery ticket?" No matter how small the chance of getting your idea implemented it is certainly improved by posting the idea. Personally I have given up on winning the beauty contest, instead I hope I plant a seed in a developer who someday works on a given feature and manages to toss it in there. Even this may not work, I have one idea which for many months had plateaued at 8-9 Kudos. Three of those were Jeff K., AQ, and Darren, Yair may have even been a straggler in that group. If support of the (un-?)holy trinity was not enough, what is? Finally, since no good deed goes unpunished I have attached a VI which will move all of your error wires to the back. I once had a need to do something to all of the error wires (and it was certainly not moving back ), but it was easy to adapt. MoveErrorWiresToBack.vi

Here is my favorite trick. Drop a matrix control onto the FP. Right-click and disconnect from type-def Make it 1D, vertical and hide the scrollbar (if you like)

Analogy: Let's say a friend of yours has called you up asking for directions because he/she is lost in the wrong part of town (probably she since directions are being requested ) . The route seemed like a good idea because it was the shortest on the map. Would you: a) Say the problem is that you should not have taken that route in the first place, tell them to back up and start over. b) Say that you need to make the next left, drive a short distance and you are there. In the event you need to go there again, perhaps take a different route. a) is probably a good answer if you are tired of being asked for directions. I think b) is what most posters are looking for, instant gratification. An effective answer (ie. good learning experience) is to recognize the specific problem the OP has and work to correct it as quickly as possible. Do not question the motives or reasoning (at this point). "You want to use a local and sequence structure to do this, here is how you would use a local and a sequence structure". After solving the immediate problem, the OP now has a working version of the code. This can be invaluable, since the OP presumably knows the logic behind it, they can understand how it works. This makes a good crutch for debugging the future version (now comes the better architecture). Plus if you are inclined to make statements about flaws in the implementation you have not only gotten on their good side, but you can let them prove it to themselves because they have working code to experiment with. Bottom line: it is a team effort, some like to hone in on immediate problems, some think big picture. There should be less tension between the two IMO, and sometimes the responders act like they are suggesting THE way to do it instead of A way to do it. There is also a trap, and I fall into it on some slow days, and that is the question we think or wish was asked is much more interesting than the actual question. In this case a simple you wired this to the wrong terminal answer gets lost in the debate over the relative importance of LVOOP and sliced bread.

You should try deferring front panel updates. You need to clear errors or leave the error in terminal unwired when it comes time to stop deferring the update, otherwise in case of an error you will end up deferring indefinitely. Shameless plug alert: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-Defer-Updates-an-Object-Property-as-well-as-a-Panel/idi-p/1292100

I just checked my ini file, and I do not work for NI so I will tell you it is "super secret..." SuperSecretPrivateSpecialStuff=TRUE

Sorry I was a bit vague there. See this page: http://labviewwiki.org/LabVIEW_configuration_file/Miscellaneous#SuperPrivateSpecialStuff Nobody, especially NI, implies any warranty guarantee, expectation for future use, etc. for these private methods. Let common sense be your guide! If (when) your hard drive explodes, you did not hear this from me... That said, have fun, and IMO it is a service to NI for users to identify which of these properties and methods are useful so they can be promoted.

Both of those properties still exist, however they are private. They are amongst my favorite private properties so I can only hope there is a good reason for the privacy. Read the VI scripting page for the ini key to turn on the private properties, but I would be very hesitant to put them into production code.