Aristos Queue

Yes, it can be done, but it isn't really a good solution. Why? Because access to a singleton object *must* have some sort of thread protection around it -- that's the entire point. If you make it reentrant, then you introduce the need for some sort of single-allocation storage. That moves you to one of these two solutions: 1. a global VI AND use of the Semaphore palette to protect all accesses to that global VI 2. an internally allocated Data Value Reference, which works as long as you only have one top level VI referring to the singleton because otherwise you run into lifetime management issues. Since singleton access really has to be serialized anyway, it's easiest to just use the non-reentrant VIs. You get zero advantage out of making something reentrant when it has to serialize its access anyway.

Ticket purchased.

You don't have a mechanism to do this, and if you find one, it's a bug that should be fixed. The class' data is private. If the class does not provide a mechanism for you to get at all of its fields, you do not have any way to get at all of its fields. This is by design.Some folks have figured out ways to take the flattened string for some known cases and manipulate that directly. That's a hack that can be made to work, but there are limitations to that approach. The Read All Attribute VIs mechanism that you mention at the start is the right, good and correct way of doing this.

At least. :-) Fourteen would be about the fastest we could roll them, and most of what you'd see in 14 months are the ideas that are at the top of the list already, the ones that already have high kudos. 26 is a better guess if these get voted up.

I've reviewed all of the 1140 ideas currently on the LV Idea Exchange. I've picked out 24 ideas that have fewer than 100 Kudos that I think are good ideas that, for whatever reason, have been overlooked by the community. If you have been daunted by the sheer number of ideas, here's a reduced set for you to take a look at and consider kudos'ing. Taking a few minutes to review them might just help your LV experience in the future: http://forums.ni.com/t5/LabVIEW/24-Great-Ideas-from-Idea-Exchange-for-you-to-Kudos/m-p/1154123#U1154123

At the moment this is true... ideally that would not be true. A class is a library and should be able to contain other classes. There's a technical difficulty we have in LV (dumb design on our part) that keeps that from happening. My hope is that this can be overcome in a couple years when we finish a larger refactoring effort. Yeah, I didn't comment on that earlier. Tst on the NI forums summed up the problem nicely:

This is by design. As far as the child classes are concerned, if they inherited from "A.lvclass" and when they load into memory they find "X.lvlib:A.lvclass", well, that's not their parent. You're asking kindergarteners to go home with strangers who happen to share Mommy's name. Won't someone think of the children?! :-) If you change the parent's name while the children are in memory, then they'll know about the name change and not load broken. In other words, parents should bring the kids with them to the Justice of the Peace when they get their names changed, so we avoid these socially awkward scenes in the grocery store with the child screaming, "You're not my mother!" :-) Bingo. Absolutely correct. Unfortunately, that trick is not on the roadmap at this time. When you changed the parent's name, did you do File >> Save All on all the children? Or did you exit without saving the children?

Nope... they'd be part of the alphabetization if I had the lone vote. That's actually kind of key -- you'd look it up by its qualified name. Otherwise things get messy -- would you want all the 2 level names before all the three level names? A.lvclass B.lvclass Z.lvclass X.lvlib:C.lvclass Y.lvlib:D.lvclass X.lvlib:A.lvlib:E.lvclass X.lvlib:Z.lvlib:F.lvclass Y.lvlib:Z.lvlib:G.lvclass That's mighty strange. This is the order I'd want them in: A.lvclass B.lvclass X.lvlib:A.lvlib:E.lvclass X.lvlib:C.lvclass X.lvlib:Z.lvlib:F.lvclass Y.lvlib:D.lvclass Y.lvlib:Z.lvlib:G.lvclass Z.lvclass

Personally? I would prefer the fully qualified name be displayed, as in "X.lvlib:Y.lvclass" and alphabatize the list by the entire string. The dialog is as it is today from feedback from various and sundry when it was created X years ago, where X is receeding further into the depths of memory.

Yeah, that's the sort of "option" that ultimately makes things less usable -- most people toggle it once if ever, it clutters the screen, taking real estate away from other elements, and it opens a source of bugs for a rarely tested code path. Every usability guide you'll ever read will condem this sort of option, and if you doubt, you can run the usability studies to confirm it. Data presentation in a dialog should be something you commit do and do, not something you waffle over. Even if a few customers find the result less optimal than another option would have been, the net is still more usable than introduction of the option.

It's not a wide dialog, so we decided to just list the unqualified class name there. I take it the path is a less usable solution than you'd prefer... We could also display the qualified name at that point. Would that be helpful? Or would you just prefer that we bite the bullet and allow the horizontal scroll bar? MS Visual Studio has decided to take that approach and show fully qualified name in all dialogs, even if it means horiz scroll. It's a usability trade off, and we could do whichever the community feels is most usable.

No. I'm saying delete version 1.0.0.2 of your class and redo whatever edit you did to create version 1.0.0.2. The mechanism works by watching the edits you make to the class. For some reason, it thinks that array is new instead of a mutation from the previous version.Oh, and I had the path wrong: vi.lib\utility\EditVILibs\LVClass

A) If you have version 1.0.0.1, you can try the edit again. B) If that subcluster is a typedef, it is highly probable that autoconversion will fail for all the same reasons that typedef constants on diagrams loose their values. Classes lose a lot of their ability to automutate at the typedef boundary. Try disconnecting from the typedef in version 1.0.0.1 and then make the edit. Note that this is one of the reasons that I suggest using inner classes instead of subclusters, so you can have data preservation all the way to the roots of your data. C) There are VIs in vi.lib\utility\lvoop to let you examine and modify the mutation records of a class. There's no real documentation for the format of the data and the notation can be arcane, but I think Kring has done some work with those VIs and may be able to help you ID the problem (assuming it is something other than the typedef thing).

I agree. I'll file the CAR.

Yes, it makes sense.In LV 2009, you open the VI template icon, modify it, apply the changes to all the member VIs, then open it again, undo the edit the template and re-apply the changes to all the member VIs. In LV 2010, you... well, since that's not released, I can't say, but it is easier.

For any class that is in memory (and a never saved class is obviously in memory), just do "name of class" + ":" + "name of class but replace .lvclass with .ctl" and wire the resulting string to the Open VI Reference primitive. Voila.

Of course it is not reentrant. When would you ever be able to show two modal dialogs at the same time? It never needs to run in parallel with itself, so there's no reason it should be reentrant.

Don't use white --- Thomas hacked white to mean "transparent". Not my favorite hack in the world. The composite icons predates the new icon editor.

Does your theme editor maintain the inherited icon layer behavior? You might already know this but I figure it is worth mentioning... Suppose class Parent has a template icon that is 32x12 (aligned top). If you give the Child a template icon that is 16x12 (aligned top right), then when you add a new VI to the child, the resulting VI icon will use the Parent icon for the left half and the Child icon for the right half. This gives you a way of having a theme in the parent class with each child class adding a glyph to that original theme and then you only have to update the parent class if you want to change the theme across your whole hierarchy.

The LV 2009 layout is what we *wish* we'd had in LV 8.2, but didn't, so now that we have it, we have to have build options to maintain functionality for existing apps. Read the upgrade notes -- the new 2009 mechanisms are WAY better than anything LV has had in the past, both for loading dynamic VIs from your EXE and for mapping to VIs that are still sitting outside your EXE.

No. A child will load its parent automatically as part of its own load into memory. OH. In that case... you want these:http://decibel.ni.com/content/docs/DOC-2875 <<< search for "Factory Pattern" for an implementation of exactly what you're trying to do. This is a very CS oriented write up of the pattern and its implementation in LabVIEW. http://zone.ni.com/wv/app/doc/p/id/wv-1295 <<< Even more detailed online presentation about the Factory pattern, how it works and why it works and variations that may be of interest to you.

There is no way to accomplish what you are requesting. A parent class is saved without any knowledge of its children. There may be infinite children on your disk, out on the network, anywhere. Some subset of those children may currently be in memory. Those are the only children that a parent knows about, and since those are already loaded, they're of no help to you. A class does know who its parent is. When the class loads into memory, it automatically loads its parent class, so you don't have to dynamically load that. Once in memory, a class can be asked for a list of all its children *in the editor environment*. You cannot do this in the runtime engine.

Correct. The inplace structure just says that the data coming into the left edge of the structure will be the same memory location as the data going out the right edge of the structure. Between the left edge and the right edge, if you fork the wire along the way, that other branch is a separate object. Under the hood LV might avoid actually making the copy if it can to save memory, but it will behave as if it is a separate object, and as soon as that branched wire leaves the structure or is connected to a node that modifies the value, or any operation like that, then a copy is definitely made.