jaegen

Lee, 1. If you haven't already, check out this forum, and especially Michael's post that's pinned at the top. 2. There are a few "CaseSelector" class properties which return an array with one element per case. See the attached VI for one example. Jaegen Download File:post-932-1160670604.vi

This thread discussed how to create a string-type case structure and set the selector strings in 7.1(using a temporary enum). Has anyone figured out how to set the selector string in added or duplicated frames in a pre-existing structure? Jaegen

This brings up an interesting point - how is Google searching through all of the open source LabVIEW stuff? Jaegen

This thread is officially getting interesting (not that it wasn't already ). Would a native by-reference GOOP implementation take care of locking? I think Aristos did a good job of answering this. This exact topic came up here at work when we first discovered that LVOOP was only by-value. We came to the conclusion that C++, while it does support pointers, doesn't do any "native" locking either - though we weren't 100% sure about this. Does it? This of course lead to a discussion about the fact that multi-threaded applications were much more difficult in C++, and therefore less common, thus reducing the need for locking (Yay LabVIEW :thumbup: ), but I digress ... Essentially, it seems that the locking feature built in to all of the existing non-native GOOP frameworks is an added feature. Here is my real question though: Do you really mean 99.9%? Right now, I think we need by-reference classes, with locking. Here's why: We have 2 main threads - HMI and Control. The Control thread uses controller classes, calling several member functions for each class on every iteration. The HMI thread can asynchronously (i.e. in response to user interaction events) call "Set" member functions for the same class instances. We need references in order for both loops (and actually even separate tasks within each loop) to access the same class instances. We need locking to prevent race conditions between the periodic Control loop and the asynchronous HMI loop calls. Can you refute this? I would love for you to, because we would really like to use the inheritance and cleanliness that LVOOP provides. (Note: I have yet to find time to investigate any of the various by-reference LVOOP frameworks proposed here and elsewhere - do any of them support inheritance cleanly?) Jaegen

Here is the MSDN Link. Jaegen

Your second question (syntax highlighting) made me wonder - has anyone successfully developed a syntax-highlighting text control in LabVIEW? Scintilla is an editor component used in a whole bunch of open source text-based projects. There is an ActiveX control wrapper for it here - has anyone used this? I downloaded it and tried it briefly, but using it wasn't as intuitive as I thought it would be, and I don't have time to pour through the documentation right now. Of course, a LabVIEW application which includes a C/C++ (or any text-based language, for that matter) syntax highlighter is probably the last thing most of us LabVIEW freaks would ever want to see :laugh: , but this could actually be useful (our big project includes a scripting component, for which a syntax highlighting editor could be useful). ... On second thought, maybe building a LV-based IDE for text-based source code editing (like SciTE, CodeBlocks, Dev-C++, Jedit, etc.) would be a great marketing tool for LV Jaegen

Well here's the only one I personally can think of that hasn't been mentioned yet: In the icon editor we already know that holding down Ctrl will switch to the colour selection tool, no matter what tool you've actually selected. Well, holding down Ctrl-Shift will also switch to the colour picker, but when you click, the colour becomes the active background colour, not the foreground colour. This is very useful for replacing text on an icon that has a non-white background: 1. Open the icon editor 2. Ctrl-Shift-Click anywhere on the background colour 3. Using the selction tool, select the text to be deleted and hit Delete (note that the background gets filled with the proper colour, not white) 4. Select the text tool and type in your new text Sorry, I have no idea what the equivalent to "Ctrl-Shift-Click" is on a Mac. Cheers, Jaegen

Here you go:

:laugh: :laugh: :laugh: Very funny - thanks for this.

Could be, but it doesn't happen in LV 7.1 ... Jaegen

Ditto on the Save dialog - a native renaming feature has been a long time coming. Jaegen

#6 If you wire an error cluster wire to a case structure, the "True" case becomes "No Error", not "Error". Jaegen

Original Post: http://forums.ni.com/ni/board/message?boar...ssage.id=206696 If you click and select a new colour, the event gets fired twice. Not fixed in 8.2. Jaegen

Enabling the "Show Constant Folding" options is not recommended. See here. In short, it does a lot more than "Show" - it turns on a bug! So, maybe it's not so bad that it's not working for you :laugh: :laugh: :laugh: Jaegen

Original Post: http://forums.ni.com/ni/board/message?boar...ssage.id=206109 It appears that if you copy the "Ring Background" part from a "Dialog Ring" to the "Frame" part of a regular enum in LV7.1.1, the control will magically become a "System" control in LV8, preventing you from writing to certain properties. Jaegen

Original Post: http://forums.ni.com/ni/board/message?boar...ssage.id=206292 (.. figured I'll cross-post some of these myself, rather than waiting for Michael to do it ) It seems LV 8.2 won't allow any numeric control (or scale) to be set to "Floating Point" and 0 Digits of Precision. Jaegen

Thank you - that brightened my otherwise rather grey day fighting with upgrading a project to 8.2. It is rapidly becoming counter-productive: See here, and here. Jaegen

Should I be concerned when I mass compile a toolkit in LV 8.2 (the internet toolkit BTW), and get this message (among others)? This means (A) that nothing has been done to the toolkit to update it for 8.2, and (B) that there is unneeded code inside VIs in the toolkit. Hmmmmm Jaegen

Well, I guess now we know we're going to see 8.2.1 before 8.3 or 9.0 Jaegen

[rant] Add my name to the list of those annoyed with the fact that this issue hasn't been resolved yet (and it's existed for several years, and versions of LV). The statement "Installing toolkits to multiple versions of LabVIEW is not supported." from the linked KB entry is a bit ripe, given that certain (newer) toolkits gladly support installation to multiple versions - it's just the old ones whose installer hasn't been update which don't. Of course now I notice this article was written in 2001, when this statement was probably entirely true, but that just means the issue has existed for 5 years now ... and this is still the only solution. :thumbdown: OK ... [/rant] ... I'll stop ranting now, Jaegen

As far as I can see, the only property we have for selecting which cluster element is unbundled in a named unbundler is the "Element Names[]" property. But this doesn't seem to work for selecting elements out of a sub-cluster. I've attached 2 VIs which demonstrate what I'm talking about. Open both of them and run "Test Unbundle Script.vi" - it doesn't seem to work. Anyone have ideas? Jaegen Download File:post-932-1157142434.vi Download File:post-932-1157142445.vi

And I'll "third" that motion - I spent about 30 seconds looking at Express VIs when they first came out, and have avoid them since. I totally agree that right-click "configuration" of a function or VI is horribly bug-prone, and much less flexible. 1. I haven't used 8.20 yet, but when I do I'm sure I'll use the primitive. 2. Small all the way - real estate is too important. 3. Anyone know how to add the primitive to the palette? 4. None - though I suppose the DAQ assistant is useful for a first pass Jaegen

Exactly. Mine is: "It's using my flow setpoint to control pressure!!" Yikes

Yeah, I knew you could, but it was just too clunky for my liking. Actually, it's more that we have one place on our UI where I plopped down a simple array control thinking that oh-so-dangerous thought: "I'll have to replace that with something more user friendly when I get the chance" ... ... now guess which item has been on my todo list close to the longest??? ... and guess which part of the UI causes confusion among all of our non-LabVIEW operators???

This is indeed wonderful news. We have been struggling with this (incredibly insidious and dangerous) bug for a long time, in a somewhat different form. It seemed to rear its ugly head whenever we edited a type def with a similar structure to your example - suddenly the unbundle was unbundling 10 identical signals, not ten separate signals that happened to have the same name but were inside 10 separate sub-clusters. This alone will likely move us to 8.20 sooner rather than later. Jaegen