Yair

You might also wish to have a look at this, just for additional reference - http://forums.ni.com/t5/LabVIEW/An-experiment-in-creating-compositable-user-interfaces-for/m-p/1262378#M529154

Cool. Cool Cool Cool.

The answer is that you can't. The abort button is supposed to stop the VI immediately, without giving you the chance to execute more code and is only supposed to be used in simple throwaway VIs or when debugging. It's not meant to be part of a normal UI or VI execution. If it's really important to you, you could create your own abort button and call the abort method when you get the event for it, but there is nothing guaranteeing that your code will not be stuck and unable to execute the event.

No tool, but the code for it should be pretty easy. I personally don't see the need, but I did post a basic example here which does this with .NET. The same thing should presumably apply to ActiveX code. One thing you might want to do is create a template of the class VI and use that as a basis for each VI. This will save you having to script all the code which stays the same.

I never noticed the Defer Drawing before, but I have an educated guess as to its purpose - the FP has a defer updates property which is useful when you want to make a lot of updates in sequence, but have them appear as a single update, either for speed or for elegance. I'm assuming this is a parallel property which was designed for scripting - if you want to make a lot of scripting operations, you don't want to waste time on drawing all the intermediate steps. I'm not sure why this is in the Application class and not in the Top Level Diagram class, but that's possibly because it's expected you would edit more than one VI or because of implementation details or because it's for something else entirely.

I didn't look at your code, but I did post an analog clock VI here, which I believe should include seconds -

One thing to point out is that this isn't an actual security threat - you can embed malicious code in the snippet and hide it in any number of ways, but at least today LV doesn't execute the code when it's placed, so a cleanup should reveal the hidden code. There are some exceptions to the no execution rule, such as XNodes, but since those require additional files, they can't be folded into the snippet. That said, I never studied the snippet or VI-stream techs closely. I assume there's no way to allow arbitrary code execution there, but that doesn't mean there isn't some roundabout way to do it by embedding special data in the stream.

A standard touch screen acts just like a mouse. For multi-touch, do a Google search. I remember some people posting some stuff about it on NI's site.

I didn't look at the documentation for each method, but the Application class has a few "Get VI XXX" methods which get this data. There might be some others there which don't start with this name. It should be fairly easy to look through all the methods in the class to see this. Of course, at least some of the methods are private, so you would need the supersecret key to see them.

In the past no. In recent versions yes. The main reason was probably to speed up loading of code, although that's just a guess. "Probably not" to the first and "maybe, but I personally wouldn't spend any time on finding out how" to the second.

There is no need to do anything.

Chris, you might wish to have a chat with your transcriber (although, you wish to tell them not to transcribe the chat ). Thinking about it further (why?), Tom Cruise was also in Mission: Impossible. You could probably just use a TC mask of that style to make the winner look like TC. Of course, if you're a proponent of the original series, you could use makeup to make the winner look like Martin Landau, but I somehow think that might be less popular. I should probably stop typing. No, really.

Here are some options: It's possible someone already did this. I seem to have a vague recollection of this, but I'm not sure. It might be easier to just build a new project with just the VIs you want. I usually try to keep only the VIs I actually need to access in the project. You might be able to drag virtual folders from one project window to another to speed this up, although I'm not sure about this. I would expect that writing a VI like the one you want shouldn't be that hard, assuming you have a small number of main VIs which hold the others in memory. Basically, you need to open the main VI and get all its dependencies (either through the Get VI Dependencies method or by recursively using the Callees property on all the subVIs. Once you have that list, You need to iterate though all the VIs in the project and see if they're on that list. If they're not, they're either orphaned or a top level VI and you should already have a list of top level VIs (in fact, they can be part of the first list). I'm assuming there's a method you can use to remove VIs from the project at that point, but I haven't looked for it. Of course, one more thing you would want to consider at this point is deleting the VI (presumably you don't need it anymore if no one is calling it). And one more of course - you would want SCC so that you can revert if something goes wrong.

Even if nothing is going on Thursday evening, you could try 6th street or other attractions. For Friday, you could try getting a tour from some of the NI guys, but I don't know if any of them plan on coming into the office after such a busy week.

One thing you might wish to look up is Norm's scripting springboard. It's a template VI which has code to operate on a selection in a VI when you press a button. That means you can create a copy of the template, add your code to it and easily test that it works and use it. It's certainly easier than having to drop controls from the palette. And again, to expand on AQ's warning, he didn't just say it was experimental. He basically said the experiment is over and that this tech would not be developed further.

To add to what Rolf said, the tan properties and methods are known as "private". If you hover over them with the CH window open, you should see them marked as Is Private. And looking at what Rolf said, you can see why they have that name. It does, but you're already aware of the problems with it. Also, it's been quite a while since I played with this, but I seem to recall there is some trick to it (e.g. it has to be the control inside the array or it has to be to set on the VI as well).

No need for a mental picture. Avert your eyes: And a hearty congrats, Jon. I assume you already got them their first beer bottles?

If memory serves, in previous years the scheduler only went live two or three weeks before the conference, so it will probably be at least two or three weeks from now if it follows the same pattern.

Actually, it probably wouldn't be. Most people are not you. You play with it, learn from it and know enough to know what to do if there's a problem. Many LV developers aren't. Enough of them will ignore or not notice such a warning to create a support burden. You can see that AQ says this happens even when people have to actively work around the protection to get to the code, so you can be sure it will happen if it's simple to access. The main difference between LV and Minecraft, in that regard, is that Minecraft is a free/cheap game developed by a single person and LV is an expensive IDE used for creating working systems - people expect the latter to work a lot more than they do the former and so the support for it has to be at a higher level. And for what it's worth, I'm with you on this. I also like access to the private stuff, but I've seen enough of it to know that there's a good reason for *some* it to remain private.

XNodes aren't officially supported by NI. They're an internal NI feature and NI presumably used the licensing mechanism to lock them out. According to this, it looks like NI won't even be developing them further. That said, I know that people have been playing with them, so it's probably possible to work around the licensing mechanism. Look for what people did here to see how they did it. Specifically, try searching for "XNode manager".

Igor, all the pages in the site have a refresh tag which points to the AES toolkit page. Also, the blog page doesn't have any content. Is it supposed to?

The document specifies that the default value for the serializer's "Skip fields with default value?" option is true. Why is that? If one of the major design goals is to communicate outside of LV ,shouldn't the default be to prefer verbosity and safety over performance? This will also mean that users who aren't aware of the exact details will be guaranteed to get the data they need.

The last comment in the document talks about right-to-left languages, but I don't think you have to deal with it. As far as I know, the sequence of chars for R2L languages is stored exactly as it would be for any other language and the display is responsible for correctly displaying it. Numbers are always displayed L2R, even you use the Arabic number system. For example, assume that this is a series of characters, where the letters represent Hebrew letters: ABCD, 1234 - EFGH. The display code should be responsible for correctly reversing what needs reversing, so the correct result should look like this: .HGFE - 1234 ,DCBA Some programs don't know that they need to do R2L, so they would display the string as it's shown in the first line. LV, by the way, only has partial support for R2L display, so in this example LV would incorrectly display the period to the right of the A instead of to the left of the H. To correctly display such strings in LV I need to place the non-Hebrew chars at the the wrong end of the string. This only refers to a simple series of characters, but since those are the only strings that LV can handle, I don't think you need to do more than that.

Like you, I occasionally try to look at various other graphical languages to see what's out there. I don't remember if I just read about VPL or whether I actually tried it when it was new, but in any case it was long enough ago that I wouldn't have any useful feedback now, other than making two off topic but useful comments: 1. You should definitely use the LV toolkit for NXT. It has its bugs (or at least did the last time I used it. It probably improved since then), but I found it a lot easier to use than the Mindstorms IDE. 2. Just right click the subVI and select Help. If the VI has a help page, it will be opened directly.

Hmm, for some reason I didn't see the image in your reply yesterday. Oh well...