Aristos Queue

Doing a bit of analysis of the growth of LV's libraries over the last few releases, and someone pointed out that the number of VIs is about as interesting as counting the number of .cpp files in a C++ program. Instead of number of VIs, we need to know how many square feet the sum total of the VIs cover to really get a feel for the growth rate, a measure more akin to lines of code. Anyone ever written a tool that you can point at a directory of VIs and figure out how the surface are of its diagram? And maybe even its average icon density? Note that this is just a fun project -- we're not seriously considering either of these measures as generally relevant to any particular decision. It just seemed like an interesting set of facts to know.

A) The parent class has no record of its children whatsoever. B) A parent class will load all of its own VIs into memory. C) A VI that loads will load any of its dependencies. Thus (A+B+C) strongly suggests that some VI that is a member of your parent class uses, on its panel or block diagram, instances of the child classes directly, thus causing them to load into memory. You may have an actual control/indicator/constant of the child classes or you may have said "Make Current Value Default" on a control/indicator of the parent type that contains a child class (if you've done this, the background of the control/indicator will be black instead of gray so you can identify it easily).

Really... haven't you outgrown the name "Norm"? I think it is time to leave behind the trappings of childhood. Like Norm of Cheers before you, it's time to pass the name to the next generation. I heard that the current Montezuma died recently. You don't really have the facial features, but that's less important these days, especially online. I'd suggest "Ozimandias" if his heart surgery goes badly next month, but I'm thinking of grabbing that one for myself.

Hm... then I don't have any clue why those are showing up. I thought it might be some weirdness with the lack of file extension (that shouldn't be an issue, but with LV so Windows-centric sometimes the cases that we used to handle well that are more common on Mac get missed; seems that's not the case this time).

Actually, they are VIs. The .ctl files are saved without .ctl file extensions. I don't have LV with me to double check, but I'm pretty sure that's where the dependencies are coming from. Double check me by looking inside the .llb.

QUOTE(mballa @ Oct 29 2007, 12:59 AM) Post the conpane of a VI that has the inputs/outputs that would be most useful to you and I'll see if I can put something together.

QUOTE(mballa @ Oct 27 2007, 09:19 PM) I posted VIs to do exactly this just a couple weeks ago. See the thread in the GOOP forum.QUOTE(mballa @ Oct 25 2007, 11:17 AM) This is a scripting node that will setup the vi to close if it is the only vi opened.I now relalize that it is not doing what was indended. Because the FIX SUBVI.vi and the _FIXER Subvis Main.vi are setup to both be opened and running I always have at least two vis opened. "Close If Lonely" checks for VIs that are not "Close If Lonely". If the only VIs that are open are all marked as Close If Lonely, then all those VIs will close. It requires a sociable VI to keep the lonely VIs company.I can't check the code right at the moment, but I recall that an open project window will serve to keep a lonely VI company, too.

QUOTE(WMassey @ Oct 28 2007, 07:55 AM) The VI Analyzer includes a test that flags any coercion dots.

When a top-level VI goes idle, all queues and notfiers obtained by that VI (including subVIs that were running on its behalf) are released automatically. So, no, there's no need to explicitly Close. Having said that, as others mentioned, if the VI won't go idle until the waiting queue operation finishes, you might need to explicitly close the reference in order to get the VI to go idle in the first place.

This document clarifies the relationship between GOOP and LVOOP. LVOOP FAQ http://zone.ni.com/devzone/cda/tut/p/id/3573 If you look at the examples that ship with LabVIEW, you'll also get a lot of insight into how classes are constructed in LabVIEW. <labview>\examples\lvoop\ Also, launch the LV online help (Help >> Search the LabVIEW Help... ). On the Contents tab, go to Fundamentals >> LabVIEW Object-Oriented Programming. You'll find a wealth of documentation walking you through various aspects.

QUOTE(silmaril @ Oct 25 2007, 03:03 AM) Just use "Defer Panel Updates" instead of hiding the specific control. Same effect, looks better to users. And if the update is long, use the "Set Busy.vi" to turn the mouse cursor into an hourglass and lock out the interface. (Unset Busy.vi to clear the hourglass).

QUOTE(Hacti @ Oct 25 2007, 04:15 AM) Editing is only supported in the development system. You cannot create a project nor edit a library in the run-time system. No edits are possible in a built application, only execution.

QUOTE(mballa @ Oct 23 2007, 10:50 PM) LabVIEW classes should generally get the same treatment. When there are multiple classes on the same conpane, each with an "in" and an "out" terminal, the preference should be if the VI is owned by a given class then that class gets preferential treatment for being in the upper left and upper right. Otherwise, mimic the panel layout.

This was reported to R&D (# 4ARC2P00) for further investigation.

QUOTE(Noxious @ Oct 23 2007, 03:05 AM) How big is your block diagram? The only time that I've seen slow down on Save for any VI is for the VIs that are many multiple screens in size. Similar slow downs begin occuring on any operation that changes the type of a wire (such as changing the property of a Property Node) as the diagram gets bigger. If your diagram has gotten to be very large, consider making subVIs. If large diagram is not your issue, I don't know anything else.

I won't get involved with the discussion about more symbolic paths to LV built-in stuff. Technical pros, technical cons, politics, blah, blah, blah... But as far as user-defined paths are concerned, there's a number of technical blocks to with having arbitrary definitions for symbolic paths as they're used on the internals of LV. But I could see someone creating a set of VIs that managed a path translation scheme for loading VIs dynamically from user-defined symbolic paths. Might be useful for one of you to put together.

QUOTE(Paul_at_Lowell @ Oct 17 2007, 03:39 PM) a) You might find the http://forums.lavag.org/LabVOOP-Design-Patterns-v10-t3845.html' target="_blank">ongoing work to translate common design patterns into LabVIEW-speak useful. b) If you don't find anything useful there, but you are able to successfully translate the Gang Of Four work for a new pattern, please let me know so I can update the aforementioned document.

QUOTE(JFM @ Oct 19 2007, 08:32 AM) The dots never help to find buffer re-allocations, which is what you're talking about here. A re-allocation is where an existing buffer gets larger. The dots help to find places where a new buffer is allocated and from that point forward you now have two buffers instead of one. The dots indicate places where your data actually gets copied and you are now maintaining two copies of the data.

I have an example of a continuously updating xcontrol. I built a scrolling LED xcontrol. It is here. There may be other ways to handle the continuous update, but this works.

QUOTE(JFM @ Oct 17 2007, 03:38 AM) The dots appear where a buffer is allocated, not where a buffer is resized. The exact same buffer is used all the way through the VI you've shown here. There isn't any new buffer allocated. The entire loop is done in place, ie, in the same buffer.

I have posted some utility VIs on DevZone for LabVIEW classes. These VIs allow you to identify whether a given control/indicator is of a given LabVIEW class. Any comments about these VIs, please make them on the DevZone page, not here.

A) There's a dot on all the block diagram constants because there's a buffer allocated there (the constant value). B) The copy dot on the Swap Primitive is on the upper input terminal, indicating a buffer is allocated for the incomming data. That's because a copy has to be made of the constant value coming in so that the swap can be performed without destroying the original buffer coming down from the constant. So the copy is of the constant, which is cheap because the default default value of any class is trivial to copy (there's only a single shared copy of the default default value). C) Looking at the version that doesn't have the Swap primitive, there's a dot on the bundle node on the output, indicating that a buffer has been allocated for the output of this operation. The center terminal input value is copied into that output and then the element data from the left-side input is copied over that. There's only one dot because there's only one buffer allocated -- that one buffer being the output buffer. Got it? QUOTE(Norm Kirchner @ Oct 16 2007, 10:59 AM) There is always a buffer somewhere for the inputs. That buffer may be local (when the VI is run top level) or it may be back on the caller VI (when the VI is used as a subVI). But there's always a buffer, so there's a dot on the input FPTerminals, just as there is always a dot on block diagram constants. You guys are really testing the limits of my inplaceness expertise. I realize your just trying to learn what's going on here, but yeesh, we're so deep into the underpinnings of LV at this point, these are details that I wouldn't expect a LV developer who'd been on R&D for five years to understand.

QUOTE(Yen @ Oct 15 2007, 05:12 PM) Use the menu item Operate>>Disable/Enable Alignment Grid, or the short cut key ctrl+# (unless you're on a French keyboard in which case it is ctrl+*). Avoids going to Tools>>Options.

QUOTE(Tomi Maila @ Oct 15 2007, 01:36 PM) I disagree. I went to type out reasons, but they basically boil down to "It confuses me to have multiple VIs of the same name that are in the same hierarchy but have no relation to each other." Sure, LabVIEW always knows what VI is being referenced. Yea for LabVIEW. It's me, the programmer, who can't keep it all straight sometimes.

QUOTE(hskupin @ Oct 15 2007, 07:30 AM) I've actually CAR'd this myself as a more general issue. When you drag and drop from one VI to another VI, the target VI needs to come into focus when you release. Otherwise your ctrl+z (to undo) undoes the wrong thing. After some discussion within the team, I think there's consensus that any drag and drop should bring the target to focus.