Yair

Nothing is preventing you from using the position properties to interleave the SPs. They don't HAVE to be one under the other. Similarly, you can attach meta data to each one to determine its order. Also, if you need dynamic adapting, then you WANT the SPs to auto-arrange, don't you? Otherwise you're locking each plugin to a specific size and all other plugins have to conform to that size and position.

I would avoid stacking SPs one over the other, especially because that means that each SP needs to know about the position of controls in the other SPs so it can avoid overlapping them. Instead, each SP could be the size of its content and you set its position dynamically based on the size of the other SPs. But you already know that...

UI and OOP sound good. Will the old RSS feed go live again? I still have it in my reader.

I haven't read this post and the emails too closely, but basically, the guy who develops TortoiseSVN says that PayPal freezed his account due to needing to comply with new regulations. I don't know if LAVA falls under the same category, but it's something to look into.

I'm guessing it's whoever got there first, but since it's not documented, you can't rely on it even if someone tells you the implementation currently favors VIs with a higher priority.

That's correct, the delay actually comes from the NI VIs. You can see this here. The attachment is no longer there, but you can see the numbers. You seem to be fine with the OpenG VIs, but you could probably also modify the MGI VIs so that you can easily save to the same file.

As far as I know, you can't set the picture ring to scale the images. That said, I haven't used one in a long time. One thing you can do is implement the "ring" yourself by displaying an array of picture controls (or several pictures in a single control) and detecting which one was clicked using mouse down events. There are different ways of scaling images, and you can see one here.

Two points for consideration: You should verify that this type of access works in a built executable. Classes are versioned and have automatic mutation applied when you unflatten old data. This won't work if you attempt to load data from the INI solution unless you do something like the OpenG variant config VIs do, where the values are loaded by name, so whatever exists in the file is loaded from the file and whatever isn't in the file gets the current value. This works reasonably well, but it should be pointed out that the built in mutation is supposed to be smarter and recognize things like renames as well.

Well, I did offer it at the time, so don't blame me. I wash my hands of this (or at least wipe them using a napkin ).

I believe it does. If memory serves, blue is scripting, brown is private and red is deprecated. In any case, even if a property is marked as a scripting property, I don't think it automatically means it won't work in an EXE. Obviously, it won't work if it needs the diagram, because the RTE doesn't know how to read the diagram, but it will probably work for something like this. In any case, the only way to know for sure is to test it, although I wouldn't suggest this to Kumar. Kumar, what are you actually trying to achieve? P.S. You can also see the details of each property in the context help or detailed help for it.

The same concept should apply. The hierarchy is determined by the top level VI (that is a VI you run yourself or using the Run VI method with the appropriate flag). If the TLV under which the init case is called goes out of memory, the reference will be destroyed.

This has to do with the way LV handles resource cleanup. When a hierarchy that a reference was created in goes idle (or out of memory), that reference is automatically destroyed. So, in your case, the top level VI in the hierarchy is the FGV. You run it, the subVI creates the reference, then the FGV goes idle, so the reference is destroyed. You run it again and call the second case, but by now the reference no longer points to an existing resource. In the second case it works because the FGV does not become idle.

I'm assuming it's a private property, not a scripting property, since it doesn't involve the code. It's quite possible that it does work in an executable. There's no particularly good reason for it not to work.

The NI forums (and IE) run on a platform developed by a company called Lithium. I was referring to the fact that the IE was a relatively new product and it seems considerably unpolished. I don't know who else uses the IE module, but it seems that our usage of it has been pushing it "over the limit" and since we managed to do that so easily, I wasn't particularly impressed with the system. I think that's an excellent point. I have mentioned to various NI people in the past that it would be useful if the whole process had more transparency and user involvement, but it maybe it's time to pick up that cause again (although I should point out I'm not too optimistic, due to business considerations, etc.).

That is only a flaw to a degree. The IE has two functionalities - it allows users to log requests and it allows NI to gauge the general interest in those requests. While the requests can be of any level, in practice you can't really offer "heavy" features, as you can't describe them simply and most users can't understand. Just ask Daklu what happened to his ideas. So, you're left with the "light" features. Some of them are pure fluff (although I have read every single post on the IE and I can say it's not nearly as many as you seem to think), but many offer significant improvements, useful polish, or both. These are perfectly legitimate. Also, I should point out that as a customer I DON'T want to design the feature. That's what NI is paid to do. Once the basic idea has been put forth it should be up to NI to figure out how much work it will be, how easy it will be to integrate, etc. While considering these when submitting an idea can be useful, it's definitely not a requirement and can't be.

Yeah, yeah, blah, blah, blah. I know all that. I guess I deserved that for writing a post mostly full of hot air and stuff that NI already knows, but I needed to get it out there, just on the off chance that it might be heard. Besides, I still want NI to implement my feature requests. Don't be. The Lithium system is far from knocking me off my feet with amazement, and it wouldn't shock me if it didn't have anything other than the Duplicate status.

Is there any particular reason you didn't use LVOOP for the transport code? This is a natural candidate for a hierarchy of classes.

Yes, it will. Now, please, go and vote for this idea - Add an easily accessible way to close an application

Stability and performance are great, but do they have to come at the price of features? Many of the suggestions in the exchange are relatively simple ones and I assume NI could say "OK, we want LV 2011 to be mainly more stable, but we also want it to have some features, so we're going to invest N developer time on doing some of the more simple requests". I assume NI is already using this logic, but N does NOT have to be a small number. If N is large enough, then this feature should be able to make it in relatively easily (and without knowing internal details or looking through the exchange too closely, I still contend that N could probably be high enough to implement at least 20 of the relatively simple ideas there without endangering the overall stability goal, including this one, although I could obviously be completely wrong). Also, you can probably count the kudos for the two ideas together. I assume there's some overlap, but you don't have to tell the managers that.

So I know I posted a link to all my ideas earlier in the thread, but here are a few I feel really should get some more love: Show the default value of controls in subVIs which aren't required in the tip strip (will allow you to stop having to write the default value in the label, should have an effect on everyone) Add an easily accessible way to close an application (everybody needs to close their EXE at the end. This should happen automatically, so vote for this. Now). Add "Add Element" and "Remove Element" to the Index Array context menu Adding a "(don't) wait until done" option to the Call By Reference node (a huge improvement if you run VIs dynamically using the Run VI method) Use the wiring tool to swap inputs or outputs which have been wired incorrectly Quick VI icon creation Add a "Concatenate Indexing" option for arrays leaving loops (relatively popular, but could still use a boost)

I went to NIWeek with François and Jon and all I got was this lousy iPod.

The listbox has a property called Top Row which allows you to control this. If you want the last element to appear at the bottom of the listbox, you'll need to calculate what the top row needs to be using the size of the listbox and the size of each row.

It should also be pointed out that this is already built-in in LV 2009 and later. It can be invoked using Ctrl+Shift+E or using the menus.

Sure does, although I definitely can't take credit for that, as I wasn't particularly interested in the feature. The CCT page has some videos demonstrating its use. You can import the snippets in any version from 7.1 or 8.2 and up using a tools menu option or an RCF plugin (respectively), but I'll let Jim point out the location, as he's a lot better at it than I am. 2009 and later let you use the native snippet import. OK, to be fair to the original version, I looked and it didn't actually require most of the fairy dust. That came later as more options were added. You can see the process here.

It's not, at least not in the RC, which is the latest version I currently have accessible, but it's safe to assume if it's not in the RC, it's not in the release either. Can't argue with that. I think the CCT is better even if you don't use its snippet feature. I would love to take credit for that, because I agree it's the best feature of the CCT, but I'm pretty sure this existed even in CC's prehistoric version, which required you to drop one VI inside another, kill a goat and sprinkle some fairy dust in order to work. In fact, I believe this feature was the whole point of the initial version.