Yair

If you really want, you can open a VI and then embed its BD window inside your front panel using the Windows reparenting API functions. You should be able to find something if you search for MDI. You could probably even use a subpanel and play with the window bounds to avoid showing the window frame, but this would probably be fragile and I doubt it's worth it. Also, it might create some issues if you have subVIs and you try to open them.

You should go through some of these. You can find a thread with some basic info on dial customizing here. You can use one of those techniques to create a basic compass. You can find a more detailed document here. Also, if you search here or in the NI forums for things like "pitch" and "roll" you should be able to find some examples.

QUOTE (JodyK @ May 21 2009, 11:30 PM) I ran the benchmark I posted in the other thread in LV 2009 a while back. I don't remember the details, but the performance wasn't significantly improved.

QUOTE (JodyK @ May 20 2009, 10:00 PM) I don't seem to have them in my clean LabVIEW, so I guess you're right. If you want a leg up, you can have a look at the conversion I posted http://forums.lavag.org/-t10449.html&view=findpost&p=44633#entry44633' target="_blank">here.

I didn't check, but I'm guessing the locked VIs you're refering to are actually from NI, not MGI. You can easily check by seeing if they're in the vi.lib folder. As such, they should be in any version of LabVIEW for the forseeable future and you don't need to redistribute them yourself. I would advise against spending time on trying to refactor NI's config VIs. For one thing, it's not impossible that they will be changed anyway in an upcoming version of LabVIEW. For another, even if they're reworked, they're going to be relatively slow because they have to do lookups, adds and replaces. I've found that if you need the speed the tradeoff of the section being overwritten is well worth it.

It's important to make the distinction, because users which have a background in text-based languages often have difficulty in grasping the dataflow concepts of LabVIEW. I'm guessing that more often than not one of the first questions they ask is "how do I create variables?". If they're lucky, they someone to explain how LabVIEW doesn't need variables unless you have parallel code. If they're not, they stumble onto locals, globals or Value property nodes and think "what a crappy language, this is so inelegant". At least if they're reasonably smart. Otherwise, they just tend to use them badly.

Just to be clear - controls and indicators are NOT variables. They are points in the code which allow user interaction (or argument/result passing, in case of a subVI). In LabVIEW, you're not supposed to care about variables, but about the data. Each node (VIs, controls, structures, etc.) has inputs and/or outputs and you should only care about the data that flows through those wires. If you have a wire coming into a case structure and connecting to an exit tunnel, the wire on the outside of that tunnel is NOT the same wire or "variable". It has data on it, which may or may not be the same data which went into the case structure and may or may not occupy the same area of memory, but you should only be interested in the value flowing through the wire and what it represents. In that sense, each wire is like a variable, but there's no real point in thinking about it that way. Now, you can explicitly create variables, but because of the parallel nature of LabVIEW, you're risking creating race conditions and bugs: Local variables are secondary access points to controls and indicators in a specific VI. Global variables are for sharing data between VIs. Shared variables are for sharing data between machines. There are other ways to pass data around, most of which are better: Shift registers, inputs and outputs on VIs, LV2-style globals, queues, notifiers and some others. You should go through some tutorials for more.

Well, calling Obtain Queue in a loop IS explicitly opening a reference. It's usually kind of pointless too, unless you want N references, and if you have an application where N*4 bytes is large enough to consume all memory then you probably want to rethink your archicture. QUOTE (ShaunR @ May 9 2009, 03:08 PM) No need to hope if you know the rule - a queue is destroyed automatically if all the hierarchies where a reference to it was obtained go idle or out of memory. Relying on that is bad design, though. You should have a release for each obtain. QUOTE Tetchy I am NOT!

QUOTE (PaulG. @ May 8 2009, 03:13 AM) Does this help?

As Ton pointed out, the True "constant" is actually a merge VI and it's actually quite new. I think it was only added in version 8.0 or thereabouts. It was probably easier to do it as a merge VI than adding it to the palettes as a primitive. QUOTE (jdunham @ May 7 2009, 11:46 PM) I assume you've already created your own subVI for this?

QUOTE (ShaunR @ May 6 2009, 10:51 PM) References for queues and notifiers are NOT created automatically. You have to explicitly request them. Even then, LV will clean them up automatically if the queue goes out of scope. LV actually got better in recent versions in dealing with references which are created automatically (like control references), so that you don't have to close them. In any case, no one is forcing you to use these (or even a new version of LV). You can go back to an old version, but I still don't see why you say that you have to worry about memory, etc. in the newer versions. It's true that the environment is bigger and heavier, but you still only have to worry about optimizations if you're doing something which challenges the hardware. As Stephen said, LV tries not to make a copy when it doesn't have to. I suggest that Ernest upload actual code we can play with to see the issue he's having ourselves.

QUOTE (normandinf @ May 6 2009, 04:12 PM) Of course not. He's going to point his finger at his head and slice it open: http://lavag.org/old_files/monthly_05_2009/post-1431-1241630881.jpg' target="_blank"> Finally, I can get the chance to prove I'm not a Trekkie. I have no plans of watching this movie. If it ever happens to come my way, fine, but that's about it.

QUOTE (vugie @ May 6 2009, 11:35 AM) I think this design is great. Apart from being more clever, it also looks like a beaker on a burner, which doesn't have any meaning to me, but I'm sure would be appreciated by many LabVIEW users.

http://puzzlesea.com/electric-box If you're at work, you probably want to turn the sound down before you open it. Hmm, maybe NI could use some of these visualizations in highlight execution to show how data travels between locals, queue prims, etc... Incindentally, this is somewhat similar in concept to The Incredible Machine and its various sequels. Did anyone else play those?

QUOTE (asbo @ May 1 2009, 08:02 PM) Alternatively, you can go to Control Panel -> Display -> Appearance (tab) -> Advanced (button), select the Menu item and change its font size.

QUOTE (professor_rumsdiegeige @ Apr 29 2009, 11:24 AM) If you right click the event structure and select Help, it will open the LabVIEW help, which includes a listing of all the events (there aren't that many).

There's a VI in the help palette for opening a URL in the default browser. If you want, the Code Capture Tool includes an example of what you want in the about window.

One useful suggestion in general for working with Office is to record what you want to do as a macro and then open the macro (to see how Word would do it) and replicate the macro code inside LabVIEW. Another option is to try running the macro itself, but I haven't tried that.

I can't say I understand this. As far as I'm concerned, this is a bug and the correct rule should be: "Events are ALWAYS handled in the order in which they are fired". I'll concede that it's a bug of relatively low importance (most of the time), but it could be a serious issue for some people. Based on the desciption you supplied, I would guess that NI could implement this by having each event go to a shared source when it occurs to get an incrementing counter which will determine its order. That won't solve the bug entirely, but if the counter is a 32 bit counter, I think you'd be relatively safe. I can't say whether the bug is worth fixing, but I definitely feel it's a bug. I think this approach highlights nicely the issue we were discussing a few days ago: QUOTE (Aristos Queue @ Apr 27 2009, 11:19 PM) This only applies if you know the rules of the system (and assuming the rules are correct). If you don't tell the users something officially, you can't expect them to know it.

QUOTE (Aristos Queue @ Apr 27 2009, 06:41 PM) That's the way it should be, definitely. Here's a VI showing an example where they aren't always (which is almost definitely a bug). I'm guessing that this is an issue which has to do with how the event structure handles a timeout when it has user events registered. I would personally rather avoid getting into the actual topic of the thread. Each of the methods mentioned in this thread have their uses and value. Queues are not all powerful, but they are generally better than globals and for applications with parallel code are often the best tool for transferring either messages or data from one part of the code to the other. The main reason for using a queue would usually be if you don't want to lose data.

QUOTE (jdunham @ Apr 26 2009, 10:53 PM) Exactly. That was the case which my example was demonstrating. Anyway, as a user, I don't see why a constant refnum MUST have the value 0. I can see the reasoning for it, but if the indicator had a value of 3428753 and I converted it to a constant, the default behavior would be for it to maintain its value (even if it's meaningless and even potentially dangerous). Until this is documented, users can't know that this will be for sure. Jason also caught the gist of my point perfectly. I was also thinking of the 64 bit reference as an example. QUOTE I'd rather have a separate namespace for queues and notifiers, if you're trying to fix stuff. I thought they do (not that I checked).

QUOTE (gmart @ Apr 24 2009, 07:41 PM) It doesn't as far as I know. The cache is fully local (the code is always checked out and you have a local copy to revert to or diff against) and I assume TSVN doesn't attempt any sort of connection to the server until you initiate a relevant action. I didn't check this, but it makes sense and I never had a problem when working with my disconnected laptop. This local cache is one of the reasons I like Subversion so much, as it makes working with LabVIEW code very fast, as compared to VSS, for instance, and allows you to see the modified files immediately.

QUOTE (Aristos Queue @ Apr 24 2009, 11:46 PM) I fail to see the big difference between this and the original form of the question. In any case, you should note that the behavior I demonstrated only occurs until you close the VI. When you reopen it, the constant is equal to 0. All this circumvents the main issue I and others brought up - should such a thing be asked, at any level of certification? I would say that this is both arcane and unreliable knowledge, as NI could change it, and doesn't have any real value, other than as a trivia question (which as we can see needs to be checked before it can be answered correctly). Ideally, any advanced developer should know to use the Not a... primitive, although I'll admit to using the type-cast-and-compare-to-0 method myself in production code in the past.

QUOTE (Christina Rogers @ Apr 24 2009, 01:59 AM) I always like proving R&D wrong: http://lavag.org/old_files/monthly_04_2009/post-1431-1240564571.png' target="_blank"> I'm posting the VI (8.0), but I suggest you try recreating this yourself first (it's not particularly hard). As a more general point, what's the relevance of such a question to the CLD and how are users supposed to know the answer? I doubt this appears in the documentation.

QUOTE (Cat @ Apr 21 2009, 09:52 PM) The check is fairly simple - load two projects, copy code in both of them and see if the first still remembers its code. The answer is no. I'm guessing that this is just an extension of what LabVIEW does with standard VIs. If you close the project, all the VIs in the project are closed as well (even if they have their FPs/BDs open, for instance. The clipboard itself is not owned by the project (at least not when you look at how it appears in the hierarchy windows), so this might actually be a bug. You should note, however, that in past versions, as long as the VIs were in the clipboard they didn't leave memory and then you could have all kinds of issues if you weren't careful (cross linking, unsaved VIs, etc.), so it's possible NI did this on purpose.