Darin

I once (briefly) looked into eliminating those clicks. Changing volume stopped the clicks, and whatever music was streaming at the time. The only effective method I found was reading/clearing/resetting the following registry key: HKEY_CURRENT_USER\AppEvents\Schemes\Apps\Explorer\Navigating\.Current You can read the current value, empty it, do your thing, then restore the original value.

Once again I will suggest that the icon of the Always Copy node should be changed to a Band-Aid. A Roach Motel would also work, but that is probably harder to draw in such a small space.

Try saving the VI as well after you add it to the class.

I was probably the only person keeping score on that one at home, but a little birdie told me that this was fixed as an afterthought to a second CAR which is probably much more useful to many of us. I do not want to jinx anything though.

The original code is a unique opportunity to "do the right thing" and still wind up obfuscating your code. It is possible, and some think advisable, to actually add comments to your regex using (?#comment). This sounds good, and the added bonus is that it quadruples the size of your regex, diluting the information content. Of course since self-perceived cleverness scales directly (exponentially?) with the length of a regex you get to feel much better about yourself. Some of the "best" code I have written is for working around the occassional (cough) bugs in LV, often the smallest ones lead to the most interesting workarounds. For example I once needed to know if the output terminal of a compound arithmetic node was inverted, a small oversight in the scripting properties. I'll describe the fix (which only gets better each time I look at it): Copy the Compound Aritmetic Node. Create a New VI Paste the Node into the BD Shrink to one terminal Check for inverted input (at least you can do that), remove invert if needed Change mode to add Wire constant 1 to input Create indicator Run the new VI Check output, if it == -1 then the output is inverted Resume scripting.. The best part, I'll wager most people either do not realize you can invert the output and the few that do, never do.

When I have a file that I would prefer not be deleted by the user (templates, default config, etc.) I usually place the contents inside a string constant inside the program and recreate it that way. One fewer file hanging around, and no chance of a user "accidentally" deleting (or modifying) it. Other than that I agree with Neil: Explicitly bundle. Remember they are called "TYPE"-definitions, they are intended to define type and not value. It is tempting, very tempting, in fact very, very tempting to use those constants to hold values. Works great if the TD never changes, but a TD which never changes, well that is really just a plain old constant.

Thanks. That is precisely what I was attempting to describe in my last sentence, my little bomb-proof containers.

I have experimented with this option to solve a very annoying problem for me: typedef constant explosion. As we all know and have come to "love", updating a typedef will explode all constants, many of which I shrink since they are used for typing a Bundle by Name. This can have many undesirable side effects. What I tried instead was to unclick the auto update which now breaks the VI. Now when I have updated the TypeDef I can treat the constant like abandoned luggage: move it to a safe location and blow it up. Afterwards I can shrink it and put it back. It is effective in this case, but I usually stick to wrapper SubVIs, continuing the luggage analogy these are my bomb proof containers.

I am actually concerned about a slightly more subtle issue. The use of subarrays means that the primitive is about as efficient as possible, no extra allocation is required. I am worried that LV will not recognize when it branches the wire and will create a copy, which it will not do for index array. It may be better in later versions with more compiler optimizations, but some quick testing in LV9 shows that Delete from Array is *much* slower than Index Array. What I do is create a large array and read the last element N times using Delete from Array and then using Index Array (with the necessary math). No array changes, I simply read the same element repeatedly. Delete takes roughly 1 sec for my test, Index takes about 1 msec.

I get a little twitch every time I branch an array wire, I have convinced myself that the compiler is clever enough to know that branching into an Index Array will not modify the array so inplaceness will survive. In most cases LV is also good at ignoring the code related to unwired outputs in the primitives, but I would be (pleasantly) surprised if the compiler recognized that branching an array into a Delete primitive to simply get the last element was also inplace.

No experience with this property in particular, but I have found the detailed help 'Available in Run-TIme Engine and Real-Time Operating System' to be fairly reliable. As to scripting+RTE, there is a bit of a semantic issue: NI lumps a lot of things under the umbrella of scripting. My rule-of-thumb is that if a property or method can operate on a VI in run mode, it is likely to be available in the RTE and to operate as advertised. Anything which requires a VI to be in edit mode is almost certainly out. The cursor property operates on a running VI, so although it is called a 'scripting' property, I do not really consider it one per se.

Although this "feature" is kind of cool, I believe the usage is a bit limited. What I do find magical about this function, however, is the following construct. Before discovering this trick I wrote a lot of unnecessary for loops.

As I suspected, the difference between debug and debug+pwd is purely statistical. I will post some of the data if I get a chance, mostly I have learned that my slow laptop makes my slow home PC look good. <OT> On several occasions I have mentioned my desire for debug/release configurations like Visual Studio. This could control more than debugging, but also FP bounds so I easily can have off screen controls in the finished VI. At any rate, the current VI property dialog dance is a pain. </OT>

I will have to do some further tests to see if there is a significant difference. The data sets and algorithm are both randomized so that may play a role as well as test order. My guess is that the difference with simply adding a pwd is not significant.

It was a very interesting question, I can see the logic of disabling debugging when you are already unable to debug. Of course my overriding philosophy is that the IDE should do exactly what I ask (enable or disable debugging/ add or remove pwd), no more and no less. As to the performance kick, disabling debugging is often one of the best things you can do for code running in the IDE. So much so that I once submitted an idea to make it much easier to do. However, some people who shall remain nameless were less than enthusiastic about it.

Here is some benchmarking of a Quicksort Implementation where I adjusted the settings of the subVI: No debugging, debugging, debugging + password. I'll let you be the judge, subVI was saved and closed for all three tests.

My favorite thing about the matrix functions is actually the Matrix Size function which works for all 2D arrays. Other than that, they are nice when you want matrix multiplication as opposed to element by element. Added bonus is that matrix multiplication uses an algorithm like Strassen's which is O(n^log2(7)) as opposed to the simple O(n^3) version most of us would write. Now it would be nice if we could have integer typed matrices....

One of the examples I have worked out leads to a plot which may become familiar to you in the next few days.

Sounds like your course is using Sedgewick's book. Most order of growth problems can be attacked in one of two ways: finding loop invariants and counting loop iterations or writing out a tree for divide and conquer algorithms. In the first case you run into the arithmetic series 1+2+3..+N which is O(N^2) a lot. For the second case imagine turning the recurrence relation for a simple divide and conquer algorithm as a binary tree: the first step divides a problem of size N into two of size N/2, the next level has four problems of size N/4 and so on. The order of the total time is the sum of all the nodes, an easy way to find the sum is to notice that each level sums to N and there are lg(N) levels so the sum is Nlg(N). Maybe there would be demand for my half-written book after all. I have implemented many classics algorithms in LV showing the predicted and measured Growth and detail some nuances of implementations in a by value language. Still working on some computational geometry.

In general I am not a fan of the "plow through an array to select a subset of items" then "plow through the subset of items" methodology. When possible I prefer to do whatever it is I am going to do when I find the element. Therefore, the code I would optimize and package for reuse would simply take an array and a start index and return the index of the first element which matches, and perhaps the element itself in this case. Sort of a special version of Search 1D array. This use case of collecting all of the items would simply use that code in a loop, with appropriate pre-allocation code. My other general point (don't have LV11 to test any of this code), is that benchmarking string operations is a dicey proposition and I often find very high variances. Be careful about drawing too many conclusions. I would check proper scaling with array size (should scale as N not N^2 or worse), and avoid the third-party code when practical. Hard to beat the good-old swap/cut method to move the desired items to the front of the input array, then use Reshape Array or Array Subset to lop of the undesired tail.

Let's all be clear here, we are talkiing about Event Structures (and Stacked Sequences if you are keeping score). Remove Frame is implemented and works just great for Case Structures and Disable Structures (only ones I have tested).

I have seen this error (or very similar) and was told that some methods have a prototype in the header file but have not actually been implemented. I'll wager the reverse of crelf, you will probably jog their memory to remove the prototype in a subsequent release.

Are you sure you aren't "rolling under" the U64 by subtracting the larger value from the smaller one? I usually use a Max & Min function to be sure I subtract the min from the max when dealing with Uints. Or just coerce to a I32.

Even with the VI in run mode before running? Never tried it but I thought it was run/edit mode changing.

Many moons ago I posted a silly VI on the dark side to post a message when a user hit the pause button. It used an XControl to monitor the Is VI Paused property (private). http://forums.ni.com/t5/LabVIEW/Is-there-a-way-to-know-programatically-when-LabVIEW-has-been/m-p/1320065#M540168 In this case, however, if your VI is in Run mode before execution then I do not believe you will receive the desired State Change Events when it is stopped. To be safe you would have to poll the execution state of the owning VI, probably inside the Facade Timeout case. I wouldn't let this anywhere near code that I cared about, but perhaps desperate times call for desperate measures.