Yair

I believe they need to be marked as public, but I'm not a .NET developer. The best resource you can get for the "interesting" stuff is Brian Tyler's blog (Lycangeek), as he used to head the LV .NET integration team.

So I'm not going to tell you guys how I had lunch outside today and how I saw people sunbathing and swimming in an outdoor pool, OK?

Do you guys want to hear about the sunny day we had today? I think it rained a bit at some point but when I came out later, everything seemed dry.

I don't have any experience with Solaris, but here are three potential options I can think of: There's an Application class property called User or something similar (which I believe should be available in 7.0) which returns the name of the current user. I don't remember if this is the OS user, or just the LabVIEW user, though. There's a VI in the palettes called System Exec, which I assume should allow you to run shell commands. In Windows, you can make a DLL call using the Call Library Function node to call into the Windows API. If Solaris has a similar API accessible through SOs, I assume you should be able to use it using the same method.

The movie is great, but I gotta ask: who do you have eating all that popcorn? Also, do you do any kind of analysis on the data (like distribution of tweets over time of day, etc.)?

LabVIEW doesn't have this. You need to know the data type at *edit time* because the Variant to Data primitive needs to output a wire of a specific type if you're to use it. IF memory serves, the type descriptor is used (or at least used to be) when you unflatten from a string, presumably because the flattened data does not keep all the subtleties of the data type, but I may be remembering incorrectly.

You really don't want to know what the winter like is where I live (suffice it to say that the last snow where I live was about 60 years ago). Also, you should know that you CAN'T stop the Madness (bonus desert scenery for those who don't like winter). http://www.youtube.com/watch/?v=PSTHMxBttlU

The link I was refering to was the link between the handling code and the control. If you have such a link and you change the label, the code won't work, but you would have no idea until you execute that code path (and that's assuming it either reports the error or the lack of action is obvious enough to the user). In my case that link is not hidden, because the reference is statically connected to the control and if you right click the control, you can do Find References and find it. It's true that the code that acts on the control is not directly connected to it, but at least it's obvious that it exists somewhere, because the reference exists, and it won't stop working when you play with the control. That's exactly what I'm saying. It's a definite annoyance, but I prefer it, partly because of this: Excellent! I want the code to break. Edit-time alerts are the best kind. If the code breaks as soon as I change something I'm much happier than if it just doesn't work when I run it. Now, I should point out that you are correct about the issues it has - it does take up way too much space and adding a control retroactively is not the smoothest thing. I should also point out that I have also gone down the same path you have - I do have places where I've placed the info in the control labels and I parse it at run-time to decide how to act (although in my cases those controls were always in clusters and I at least got the cluster reference statically, so at least THAT can't break). For a large number of controls of the same type with the same code, it's usually a better method. As is often the case, it's a metter of deciding which tradeoffs you want to make.

Personally, I can't stand using control labels to get a link to the control. It creates a hidden link in the code which is impossible to find and very easy to break. Here are some alternatives: You can find a very simple example here of how to bundle references into arrays which serve as groups. You can then act on these arrays as units. Each control can easily belong to more than one group. Here you can find a JKI RCF plugin which will allow you to very easily create an array of references for any number of controls you select. You can then operate on these controls by index. This is better IMO than the label method because there's explicit code. Here you can find another plugin which will allow you to easily create a typedef cluster of references. This is the one I like the most because the code is explicit, but as you mentioned, it has the downside of potentially taking up a lot of diagram space.

And you don't see any problem with these two statements? A linked list has pointers as part of the mechanism. AQ posted code which allows you to swap two pieces of data without using references, but that would only work with two pieces and would only guarantee no copies if you do it exactly right. You should note that the problem is not with a recusive data structure in itself. The problem is that you want not just the data type to be recursive, but the data itself to be recursive as well, which is kind of a problem in the data flow world of LabVIEW.

I don't know why the option isn't there, but here are some options: Move the file out of the folder or the library, then remove it. Open the class separate from the project, then see if you can remove it. Edit the lvclass file manually.

I'm not sure I understand the problem you're running into (I haven't tried this myself), but DVRs (a new feature of 2009) can probably simplify the implementation a lot, because they're pretty much the nearest thing you have to a pointer and making a copy of the reference is cheap. You would still need to traverse the list (iteratively, not recursively, which I assume is what AQ's example does as well, although it's been a while since I've seen the code) to get to where you want, but that's a basic part of the design. This feature won't help you if you're trying to create a cyclic graph, because to access the data a second time, the first lock must be released.

I would guess that the app font is the most likely suspect. As the name suggest, the app font is not a specific font, but an application-dependent font and I think the default one in Vista and 7 is different than the one in XP (which I believe is Tahoma). You can explicitly set the app font by adding a line to the executable's INI file (or to LabVIEW.ini, if this is in the ADE) which is basically AppFont=Tahoma, 12 or something similar, where the number determines the default size.

I thought it was a sphere object (maybe for the 3D picture control) which has been flattened for saving (as evidenced by the binary stream below it).

I think you mean "science SHOULD'NT work that way". If you look throughout history, scientists are not exactly above being petty, vindictive and short-sighted. When you couple that with the constant fight for limited resources (you can't do research for free), you get even more justification to get the Money Man to give the money to you and not that pesky scientist with the opposing theory. FWIW, I am skeptical in this issue. I do think that GW is probably represented incorrectly. The difference is that in my case it's just a feeling, nothing more, since I don't have anything concrete to base that feeling on. And I certainly agree that sometime people take one side and believe it to be gospel even without basis. That does not mean the other side is necessarily correct. Debate, in itself, is not helpful, as this is a scientific issue - either the scientists can tell us what's going on or they can't. After that, it's a political issue of deciding what to do, and that's where the debate is relevant.

Maybe he's too busy making films? I haven't seen Flatland, but the book was certainly good.

I wouldn't call you a denier, nor would I call you a skeptic - it seems to me that you picked a side (which happens to be the "defending" side at the moment). I have no tools to judge (and to be honest, I doubt there's a single person on this planet who does have the tools to give proper answers to many of these questions), so I profess my ignorance. Like crelf said, the basic point of my last post was that you can't make a valid claim from one side while ignoring the fact that you can make the same claim from the other side.

If you wish, I'm sure we can find politicians who believe GW is a scam and metorologists and programmers who believe it's real and use that exact claim in reverse. Why don't you believe them?

What doesn't work? VI server works perfectly fine in projects, but each project is considered a separate "application", so you have to use the Open Application Reference primitive and use a different port for each project (through the project properties) if you want to communicate between objects. I didn't look at the example, but I'm assuming this is the source of your problems.

As I mentioned in the NI forums post, the library includes some VIs which are called dynamically and need to be explicitly included in the EXE.

I calculated that this is actually 2.3% and if 97.7% of the population is working it means they are below animal level and are prostitues of the secret police. And in case it wasn't obvious enough, my point is that making a claim like that is unfounded, because what makes 4-6% the magic number? I don't claim to have an answer, but my basic point is what crelf and others have claimed - you (or at least I) don't know, so this debate is mostly pointless (which is basically why I haven't participated at all in this discussion).

The basic concept you're looking for is plugins. As for passing the data, creating user events or notifiers for each control is probably your best bet. Here are two options which may save you time and give you ideas. The first is called "LVx" and can be found in this site. The second, which might be more relevant, can be found by searching the NI forums for "dynapanels" and I believe its code is open as well.

I didn't look at how the plugin works, but you probably could adapt it to work with a URL - if you feed a URL followed by "[text]" (as in "]http://whatever[text]) into the Datasocket Read primitive, you will get the data in that URL as a string, which you can then either save directly to a PNG file, or copy straight into the clipboard (which I assume is what the plugin wants).

The basic answer is no. If you want to do stuff like that, you need to use a real queue where you can control these things. As for the single queue theory, as far as I know, even that is not true and there are at least two queues (one for user generated events and another for dynamic events), not to mention what happens when you have filter events, which interact with the queue of any event structure which handles them. In any case, since you can't access this information, I see it purely as an implementation detail (or a bug, actually, since under certain conditions it causes unexpected behavior).

That was basically the question (actually it would have been "is this issue fixed?"), but the answer actually seems to be "no" to both questions. They say this was fixed in 3.0.5 and your image shows that LAVA has 3.0.3 (I checked now and the problem is still happening). Is that version still not available publicly?