Aristos Queue

In fact, parent classes never know about their descendants. No data about any child classes is ever saved in a parent class, development or runtime environment.

Kind of... without the selector being visible, there's no way to select the alternate functionality, so it might as well not exist. And without the selector, I think it is reasonable for any user of the the poly VI node to assume that all the functionality is available just by wiring inputs. Drawing the instance doesn't really help with those usability issues.

Yeah. I don't like that at all. I know it works, but visually, it tends to be a problem for me. For one thing, the location of that feedback node floats around just like the stop terminal. For another thing, I still get twitchy about that one wire running backwards on the diagram.

I asked around. Here's the best answer I got: Inlining with the token in LV 2009 can't handle front-panel terminals inside structures, locals variables, property nodes, invoke nodes, or control references. I'll bet it is the FPTerms inside a structure node that is your problem as that would be the least obvious of items on this list.

Crelf & Daklu: You do realize that this is possible in LV today, right? And has been around since at least LV 6.0? The DAQ VIs are rife with this usage.Create a PolyVI... On the configuration page for that PolyVI, there's a checkbox for "Show Selector by Default". This makes the poly VI instance selection ring appear under the node when you drop it. Then when users wire up to the node, they can select from the ring which bit of functionality they'd like to use. It's almost like having an action engine where the action is required to be a constant directly wired to the node. When I first learned about polyVIs, I filed a bug report that the poly VI wasn't broken even if two member VIs had the same inputs. Someone pointed this checkbox out to me, and I thought, ah, ok, now it makes sense. I let the bug report close as "not a bug." I did suggest that if there are two VIs added to the poly VI whose inputs are identical that the poly VI should be broken unless this checkbox is checked. That was rejected because it might break existing poly VIs that users had. Makes sense, but you should still be encouraged to use this checkbox for that case. Maybe you knew all that, but it sounded like from your post (Daklu's in particular) that you didn't.

To be clear: the upcast coercion dot has no effect at runtime. It is not the same type of performance penalty that the coercion dot from int to double represents. We've talked about wanting two different coercion dots, but that's hard to provide since red appears to be the only color that most people can see in that small a space and there's no way to put a different pattern when you only have 6 pixels. So all the coercion dots look the same. Typedef to not-typedef-but-still-same-type (and vice versa) is another coercion that has no runtime performance penalty.

Personal choice. Most documents you'll see from NI use the while loop, but I like being able to read, at the start of the loop, "This will only execute once." The stop terminal for the while loop can drift around a bit, and even if it was fixed in place, it's still at the right side of the loop instead of the left side. Wiring the N with a 1 means I recognize this type of loop as soon as I start reading it, instead of scanning across it to see the constant wired to the stop terminal.Under the hood, my understanding is that they both convert to the same assembly code, so it doesn't matter which you use.

Bingo.

If you mean "make the Singleton inherit from another class", that should work just fine.If you mean "inherit from the Singleton", that's correct. This particular implementation is not intended to support inheriting from the Singleton. Singletons don't generally have inheritance in my experience -- there's supposed to only be one of them. If you want inheritance, there are variations on this theme that can be applied. All of them involve passing in some sort of "key" that says which Singleton you would like to use or moving to a "get and lock, then operate, then unlock" paradigm. But these are generally undesirable for singletons since even asking the question "which of several singletons do you want?" is somewhat ridiculous, since singleton should mean "there is only one."

It's been in my head in theory, but I hadn't had time to type it out. I declined to make it a shipping example in LV 2009 because the DVRs were new and I needed to see how they'd be accepted (or not) by the community. Including it (a cleaned up, more commented version of it) in 2010 is probable if the folks here think it solves the issues.

In LV 2009, this is how I would recommend that the Singleton pattern be implemented: AQSingleton.zip No wrapping library. No replication of VIs caused by having public wrappers and private implementations. No excessive copy overhead. And, yes, thread safety for parallel public calls. This demo class implements three public functions: Set Path, Append Path (which does a read-modify-write) and Get Path. Note that there is one minor issue with this implementation *if* (and only if) you have multiple top-level VIs all using the same central storage and the one that accesses the global first quits before the others are ready. The workaround solutions for that are ... problematic. It is in the set of "holes in the LV language" that we've been slowly patching o'er these many years.

I thought a fewton was something you slept on. :-)

Then this wasn't a singleton. By definition, a singleton class allows only one copy of the data to exist anywhere in memory ever. It should be impossible to create a second copy. If you can create a second copy, it's not a Singleton. That's just a reference to an object.

Poly VI A.vi contains instances B.vi and C.vi, each of which has a unique conpane. There's no reason a descendant class couldn't have an override for B.vi or C.vi or both. It wouldn't allow the child VI to add D.vi to the poly VI, but it would let the child customize the behavior of the conpanes as given.

The buffer is still allocated. That doesn't mean anything is copied to it when the VI runs. That's true up through LV 2009. In later versions, ... oh... nevermind.

You want to post your question here: http://decibel.ni.com/content/groups/enhanced-icon-editor-2009

For the record, the icon directly in the .lvclass file is just the icon of the library itself. The icon of the .ctl file is embedded in the private data control, which is itself an entire .ctl file embedded inside the .lvclass file. Unfortunately, you can't just copy/paste that text directly into another file -- its a binary file that has been escaped in order to be saved inside the .lvclass file. Assuming you can somehow extract that from the .lvclass file, there are ways of extracting the icon of a VI without loading it into memory (I forget the name of the VI Server method that does this, but it does exist). I would *not* try loading the .ctl into memory directly -- control VIs that are tagged as private data controls make a lot of assumptions about the conditions under which they are loaded (notably that their owning library exists and is already in memory) and you'll almost certainly crash before the load finishes. But reading the icon data out of the file should work. Again -- the easiest way would be to just load the class into memory and then use the Icon Editor VIs to edit the icon.

Can you make it reentrant? If you can, I believe this will allow the inlining. A non-reentrant VI will block inlining if it contains any asynchronous nodes (like a Dequeue Element). Why? Because non-reentrant subVIs are mutex locks (ie two callers to the same subVI cannot execute simultaneously), inlining a non-reentrant subVI that includes asynchronous nodes would create timing changes to the behavior of the nodes, and so inlining is barred. I *think* that if the subVI is made reentrant then we ignore that check because inlining the reentrant subVI doesn't create any timing changes since two callers already could've executed in parallel (that being the point of reentrancy). (For the record, I have only observed others using this token, never used it myself, so I'm definitely not speaking with any certainty in this.)

No, no other reason. It is something that LV R&D would have to implement, and it has never percolated to the top of the priority list. Yep. I agree that it's more work, but it's not a hack, insofar as we said, "Well, there's a reasonably obvious way to make this work. Given that, let's deprioritize the ease-of-use feature for having poly VIs contain dynamic dispatch VIs directly." It still isn't on the roadmap for any of the near term releases. It is not on the Idea Exchange... you should go post it there and see if it drums up enough support to get attention.

Here's the original attachment: Map_Class.zip It was deleted when LAVA got wiped out in early 2009.

Yep.

The tag is nothing special. It's the same tag used by all VIs for the Icon Editor. Go use the VIs there to manipulate it.

The pool will grow if the need for more parallelism arises. In other words, if a thread requests an instance and all are in use, another will be allocated. It's a standard "grow by double until threshold then grow by threshold increments" algorithm -- so you start with one instance in the pool. The first time the pool grows, it doubles to 2, then 4, then 8 and so on until some threshold... in this case I think it is 32, but I'm honestly not sure... at which point each request increases the pool by the threshold amount, which, again, I think is 32.

Ok... I guess it could've been one of *my* LabVIEW classes. :-)

Or that someone used the Icon Editor and drew a triangle with a plus sign on it. Occam's Razor, man, Occam's Razor.