Yair

Two relevant points - In 2009, Quick Drop also indexes VIs from the current project, so you can use that to drop VIs from the project. Modern versions (I believe it started in 2009) have the locate in project feature built-in, so there's no longer a need to install the OpenG version. If memory serves, it can be found in the File menu and I believe it has Ctrl+Shift+E assigned as a shortcut.

Chris, registration in general is useless if your aim is to distribute the code. To paraphrase a line from Stephen Hawking, any obstacle you place in the way of downloading will cost you half your downloaders. I know that I wouldn't register unless I *really* wanted to download the code. From that perspective, I agree with the policy Mike stated above. Which isn't to say there aren't legitimate reasons for requiring registration. I just don't think it's correct for the LAVA CR.

I wouldn't call it lying to the customers, but I would agree that I consider the event structure to be a pretty basic tool, and the lack of edit support for it makes the base version crippled. However, it's quite possible that NI targets the base version at users which it expects would not need to have an event structure (e.g. because they only write simple VIs which are run once by pressing the run button and have no "need" for handling UI input). Eventually, if the base version exists, you have to take some stuff out of it to make the full version worth while and it's a legitimate business practice. Ultimately, the list of differences between the base and full version isn't very long and if you don't check what those differences are before you buy, that's your problem. Which isn't to say this isn't annoying. I have a cheap and simple phone and I'm always annoyed that its search feature can only match the beginning of a string (for instance, if I had you in my phone book, typing "ch" would not find your name. I would have to type "an" to get it). This feature is not missing because the makers of the phone didn't think of it or because the code for it is complicated. It's missing because they decided that only the more expensive models would have it so that you have a reason to buy them.

Thanks for the replies, I'll add all those to the list and try to remember to update once we do the project and see that whatever we put in works well. Re. Lantronix, I saw that their stuff looks nice and already added it to the list. The last time I used one of their products it was a single port device server and my only memory of it is that we had some sort of issue and configuring it was annoying (I believe it had some sort of wizard which was displayed when you telnetted into it. I assume modern versions have a nicer GUI).

The main issue with the NI model is the price, particularly as we need to get several of them and the price difference adds up. I will add it to the list, though.

Cross post at NI - http://forums.ni.com/ni/board/message?board.id=BreakPoint&thread.id=11462&jump=true I'm looking for recommendations for Ethernet to serial adapters (also known as device servers) which have 2 or 4 RS-232 ports. We don't need super performance or anything like that, just something that will work decently and not break down. If you have worked with a product you liked (or disliked) that's what I want to hear. The only one with this number of ports we used was from Advantech and our impression wasn't good. I've used ones from Tibbo as well and I have nothing but good words about those (in case you ever need such a device), but unfortunately, the relevant models only have one serial port.

No, but they do have a pilot program for a web-based front end that uses other technology. If you join the pilot, perhaps you can convince them that HTML 5 is more appropriate.

Or a typedef with a large default value? I don't think I would have one, but I could envision someone creating this data as default to avoid having to allocate it explicitly.

Does that mean that there's a new buffer allocation? Presumably such an allocation won't be a big hit, since default data usually doesn't take up much space, but it is a thing to consider if handling large data structures.

You can code this yourself by making the MCLB disabled or an indicator and using the Mouse Down event, coupled with the method which tells you which row was clicked based on the coords to do the entire selection programmatically. This has an additional advantage in that the user does not have to hold the shift key.

Have a look through the LV help. It details which files are specifically designed to be ignored by SCC. If memory serves, these are the only two files in that list, but there might be others.

You can also relax a bit more, since it's actually ~50 days, not ~25.

Not unless they need it as part of their functionality or if I would have reason to suspect their performance would be improved by it. As far as I can tell, this is also NI's policy with vi.lib (you'll note that most VIs there are not reentrant).

Which was why I suggested defering the updates inside the facade VI - then the control becomes contained and there's no need to do this yourself. You could probably create one yourself.

Rolf, I assume that if anyone would know, you would - the only file type I can remember this locking happening to with reasonable certainty is an .avi file. Is it possible that Explorer somehow sent the open command to LV as well because the extension had "vi" in it? I'm assuming not, because my understand was that the extensions are explicitly recognized using CLSIDs, but it's a guess.

You should note that reentrancy does not necessarily mean improved performance. When you have reentrant VIs, there needs to be memory allocation and book keeping for each instance, something which will have a greater impact the more reentrant VIs you have (although I don't know how pronounced this effect is). This is supposed to be mitigated if you use the shared pool for clones option available in 8.5 and later (since only N instances are allocated for each reentrant VI). Obviously, you also won't gain performance if your non-reentrant VIs aren't actually blocking. I'm assuming that the execution trace toolkit NI sells should help you with seeing which VIs are bottlenecks, although the standard profiling tools might also be enough if you simply look at the number of runs.

I didn't look at your benchmark, but you could probably implement this yourself by opening a reference to the VI in the relevant class during the first call and then using that reference to run the VI by-ref for all calls. The VI itself will then not need to be DD - you simply need to get the VI's path and open a reference to it.

I got the same feeling recently in his other thread when he basically compared the "communist Jews" to the Nazis, which would have been the perfect chance to invoke Godwyn's law. I'm not a fan of censorship at all, but there are some lines which need to be drawn. Unfortunately, my plea to the proper mods seems to have gone unanswered. Some of my best friends are Mossad agents. I don't know which ones, though.

Upgrade to LV 2009, where this behavior was changed.

If memory serves, setting the FP Window state to Minimized and then to Standard works, but it's been a while.

It happens occasionally, but the only way to notice it is to try to move or delete the file which is locked, so you won't notice it if you don't do that. The main problem is that I have no idea what's causing it. This is on Win XP SP3, LV 2009. I think it also happened with LV 7.0, but I'm not sure.

I don't just think it would be interesting. I think it's highly desirable. That's why I created an idea in the idea exchange for this - see the link I posted in reply #9.

This is a problem with the Selection List[] property - the elements in that list are grouped by selection (so if you made 3 consecutive selections while pressing shift, you'd have three "groups") and within each group the elements are ordered by their Z-order, for some reason (tabbing order would probably make more sense). In any case, the plugin is open source, so you can modify it to sort by label if you want. If you want it to also keep its current behavior, the RCF supports a configuration dialog, so you could have this as a boolean option.

The default should be to post it. Even if no one wants it right now, someone might want it down the line.

By the way, if you're using a more modern version of LV (8.2 and up), you should probably use LVOOP for handling inheritance. It's built-in and in active development, so it's easier to work with and understand.