Darin

So, as I said "No such luck". And the reason is much simpler: the reference could change and the name remains the same. No guarantee of a loop invariant.

Obtain Queue using a name is planted in my brain as a serious performance bottleneck. If you compare a simple enqueue in a loop the difference between looking up once and looking up each loop iteration can be the difference between a few msec and more than one second (order of 20000 iterations). If you were to place an obtain queue inside a loop with a constant name I would think it could be recognized as a loop invariant and optimized for you. You know, have your cake (no long bending wires) and eat it too (super fast). No such luck. What I do instead if I need the name function is construct a look up table using variant attributes. With a constant name the variant lookup code is optimized and is essentially as fast as using a single obtain. With a control inside the loop for a name (breaks loop invariant) the attribute lookup is still much faster than obtain queue. It is a way to get the elegance of by-name lookup with much less of a performance hit than using obtain by name. What do you lose? Primarily the validity checks you usually do not care about when you are trying to shove data around quickly. I figure that the enqueue/dequeue will complain soon enough I do not worry about catching the error upstream from there. (These are vague recollections from LV11or12, maybe it got a lot better in LV13)

It is cool, very, nice, very well-written, nicely laid out with great icons and all of that, but until it sits in vi.lib (like it should!) and/or I can open up the detailed help on Flattened Data and see the picture format documented I consider it hack code. It is not derogatory, a lot of the coolest code I have relies on undocumented features. And I would double check your value for 'new font', I have it down as opcode x1F and not x00. Does not matter for simple translation obviously. Also, my (hack) code does the operation inplace instead of rebuilding the string and seems to be about twice as fast, important for complex drawings. Tips for those who go down this road: If you are really shifting everything, consider the origin property. Do not forget that the zoom factor can be !=1. If you are simulating a drag I would consider using a separate picture which contains the drag objects drawn on top of the picture (I usually draw the drag objects grayed out in the main picture). This is much better than parsing and reparsing the image if you have relatively complex pictures.

Somewhere in my harddrive is buried a library which scans the opcodes of a picture and applies translation, scaling and rotation. The text rotation and scaling and bitmap operations are a bit involved, and I never bothered to deal with rotating greyed out rects, (other rects are converted to polylines). It is kind of cool, but I would probably not get too close to "real" code with it since it is deep into hack country. What it also did was delay me from doing what I really should have done earlier, implement a real OOP drawing library. Implement a few basic shapes (start with the LV Picture primitives), and a group or collection object. Each object gets an origin, angle and scale and methods to translate, rotate and scale. Now instead of blue squiggly wires everywhere you get (blue in my case) class wires everywhere. And then you can reach nirvana, retire the LV picture functions altogether. The render method of the objects can be overridden to be LV Picture, SVG, eps, Canvas, .NET, whatever. Once you see a few anti-aliased lines, circles and text you will never want to go back. IE (easiest browser for ActiveX integration) is closing the gap with the better browsers on handling HTML5 and SVG, it simply unleashes a whole new world. Rotated text caused problems last time I tried with IE so it is not all systems go quite yet. But it is getting close. Of course, it not only has to be fixed in the browser, but fixed for long enough that it becomes reasonable to require users to update. But I digress, you probably need to get to point b from point a so Norm will likely be posting an opcode parser in the not too distant future. I'd post mine, but the bitmap and rotation handling bloats it considerably and the fact it comes from LV3 or 4 makes for interesting reading. [it says a little about LV3/4 and a little about how I programmed when I was using LV3/4 (not to mention it started as a hack).]

At least it is listed in the upgrade notes. The suggestion there is the obvious one of putting the ctl into a VI, may not help you much. Bummer.

You guys really need to discover the GetPlotAtPos method of the Graph/Waveform. Where is the LAVA Rube thread?

Ah, the good old white stretch to the right of the FP menu bar. Drives me nuts, I try to chalk it up to the cost of doing business on Ubuntu. I'll download and check it out sometime. I am curious how it compares to OpenCV.

Regexes and scripting are two of my favorite things. In this case I would use the Terminal.datatype property of the LVClassConstant and pass the value to the GetLVClassInfo.vi found in vi.libUtilityVariantDataType

I would clarify that old features do not seem to regress in the new versions, but most new features need at least the first SP to get polished. Usually this means fixing bugs found too late in the beta cycle. 7 was a good version in retrospect. At the time it gave us Express VIs and worked hard to shove them down our throats. Having repressed those memories does seem to improve my outlook on it. I just reinstalled a copy this morning. Another cool feature in LV13 is the scaling of the event structure dialog. I do miss the old getting started window, I think I will have to hack that. Harder now with those darned PPLs.

I find that all LV versions can be stabilized. Any feature which leads to crashes is basically dead to me. Then it becomes a question of how useful a version is. 8.2 and 9 were both very good to me. These days I consider the time between August and January to be the beta period and the release of SP1 to be time to dive in, especiallly when it comes to new features. There seems to be a relatively long time without an f1 patch, could be a good sign for 13. Favorite feature is not a new one per se, but rather that the conditional tunnels no longer suck.

I think AQ takes the opposite approach that I would take. Instead of putting the burden on every VI with an open window to signal the floater, I would put the burden on the floater to track the active window. This is relatively easy with the VI Activation event and the new-to-LV13 VI Deactivation event. Depending on how you launch the floater VI (static/dynamic) you may have to pass it the "parent" name.

I am sure the LAVA folks maintain a database for ticket purchases...so yeah I would print that sucker out.

Certainly only top men have this problem. Top. Men. (Those who do not get the original reference should at least get the Family Guy homage)

I am sure they have top men working on it now.

This is an oldie-but-goodie bug: http://forums.ni.com/t5/LabVIEW/Multicolumn-Listbox-Keyboard-Navigation-Bug/m-p/1286778/highlight/true#M533821 Similar behavior for the normal listbox as well. I have "solved" it by taking full control of the keyboard navigation using events. And yes it is a pain.

Cat fight!

[chorus] Oh Lord it's hard to be humble when you're perfect in every way. I can't wait to look at my diagrams cause they get better looking each day. To know my G is to love G I must be a hell of a man. Oh Lord it's hard to be humble but I'm doing the best that I can. [chorus] I used to have a girlfriend but she just couldn't compete with all of these love starved women who keep clamoring at my feet. Well I prob'ly could find me another but I guess they're all in awe of G. Who cares, I never get lonesome cause I treasure my own BD. [chorus] I guess you could say I'm a loner, a cowboy outlaw tough and proud. I could use lots of classes if I want to but then I wouldn't stand out from the crowd. Some folks say that I'm egotistical. Hell, I don't even know what that implies. I guess it has something to do with the way that I wire my unmatched VIs. [chorus]

C++ was not born by writing a new compiler, instead it was born by writing a pre-processor which converted C++ to C so the existing C compiler could handle it. Certain elements of the syntax were clearly influenced by making the pre-processing easier and not always by what made the most sense. How would you implement OOP in a text language and how would you implement OOP in C are two different questions. Likewise, LVOOP was not designed from the ground up, but rather cobbled together leveraging existing LV elements as much as possible. Once again there are two questions. The question asked by the OP, How would you implement OOP in a graphical way. And the question NI had to answer, How can you take the absolute minimal set of OOP principles and implement that in existing LV technology. My own opinion is that the implementation of OOP looks poor in the context of how would you implement it in a graphical language, but quite reasonable in the context of mapping OOP to existing LV capabilities. Introducing OOP to LV programmers usually leads to much happiness. Introducing LV to OOP programmers usually leads to a fair amount of frustration.

I was going to suggest the single interpreter approach, did not know if the variable persistence would be a feature or a bug. I figured it would be ok in most situations since you should be initializing values anyway.

What you have failed to realize is that the ads appear and then go away for premium members, so there is a subliminal effect. Now where is the emoticon with an Al-foil hat?

Is this thread why I am getting LogMeIn banner ads on LAVA or are you guys susceptible?

The short story is that numpy is not compatible with multiple interpreters being launched in the same process (say LV IDE). I have not seen the code for LabPython but I will wager dollars to donuts that there are calls to Py_NewInterpreter() in there. This would explain the issue. A quick test would be to run the same code from two different VIs. I bet that the second VI will hang in the same way that the first one would on its second run. This points to a single global session having multiple interpreters. You should be able to get around it by building executables, or disabling threads in numpy (yuk). As for blame, there is a little for everyone, but I tend to scale by cost, so I am not very hard on things which are free. Python made rules for extension modules and numpy followed those rules. At the same time, Python supports a method for launching multiple interpreters in the same session which LabPython takes advantage of apparently.

Oh yes, LED off, that is a very tempting choice. Some people are crazy enough to turn subVIs into XNodes for no other reason than to draw icons with 24-bit color.

The icon editor is happily letting you pick and choose from the full gamut of 24-bit colors. The actual icon display is only 8-bit color, though. Not a problem, you say, who is going to have more than 256 different colors on a 32x32 icon? Unfortunately, those 256 colors are fixed by LV so you are seeing what LV deemed is the closest color amongst the 256 it has predetermined to display. Many editors have a button you can push to coerce the arbitrary color to the restricted set (say Web-safe colors for example). I don't want this in LV, though, I want 32-bit color (ok I'd settle for 24). It would be nice, however to have an inkling of what is about to happen, since I have found many times the "closest" color chosen is probably not what I would choose.

That is a lot easier than my fix for LV9 which predates the InsertPoint property as well as PaletteString. LV10 was greatly simplified with the PaletteString addition, but the rewiring was still interesting. Now it looks like Darren got the method changed to his liking, but he did not get around to using it. Fortunately for the rest of us, the former is much harder than the latter.