Djed

Yes, that distinction generally determines when you'll see this behavior.

The exact details of when the exact clone is exactly "reserved" do vary for many reasons. It's not necessarily deduce-able from the diagram since the compiler tries to optimize things. The caller VI might grab a clone once and hold onto it for a while or it might grab it exactly as it needs it. And yes, SD versus DynD also play into this. Dynamic Dispatch I believe is always grabbed at the last minute because we have to deduce the right VI to call and it might vary between loop iterations, etc.

"Shared Clone" reentrant subVIs are assigned to a callsite from the pool of free (not currently being run) clones *at the last minute*. This means that generally if you go click on a callsite, LabVIEW can't possibly know which one will actually be run by the caller VI, so LabVIEW just opens the "master copy". However, if that callsite DOES have an assigned clone because the clone is running exactly when you click on the callsite, then LabVIEW can open the right clone! This can be very hard to do unless the subVI takes a long time to run or you are already debugging thanks to hitting pause or hitting a breakpoint or stepping.

Daklu,You are in the ballpark on those hidden prims but I have to sadden you with the news that we never finished them. You're lucky if you don't immediately crash the second you try to run a VI with those nodes on the diagram. Sorry these aren't going to be useful nodes to play around with. I'd be shocked and fall out of my chair if you found these used in ANY vi in vi.lib.

Off the record, NI put in stronger VI password protection purely as a user-feature, not as some sort of DRM. Our own diagrams that we do password protect are much less important than protecting our customers' IP. If you are having a problem accessing your own VIs due to mutation issues, please contact support.

Generally there is little difference between the matrix data type and a 2D array. However, there are a handful of mathematical operations that act differently. Just multiplying 2D arrays of numbers the way labview does is different than matrix multiply.

AQ's not trying to be mean in denying you internal information on xnodes. First, such documentation was written for internal purposes and as such contains "classified" information. Second, xnodes were not designed as a feature for customers but as an internal tool. As such, believe me!, they are buggy, under documented, flaky, dangerous and unfinished. They are nowhere near a feature we can support and we are not allowed to talk about them. This is not really a "protecting you from yourself" but rather not publishing an unfinished, buggy feature. Maybe someday we'll have the resources to finish and productize the feature. But for now, we are supposed to answer "No comment" according to the lawyers. =)

Can you file a bug report on this or post some (preferably simple) VIs that reproduce this issue and I'll file a report. I have an idea of one thing might be going wrong internally.

Have you considered just using a latched boolean? Boolean controls that are "latched" reset themselves to the default value after they are read once on the diagram.

I believe the answer is that if you wire from one diagram to the next, it will automatically create a tunnel for you, much like when wiring on an actual diagram. I am unsure about wiring to a structure boundary. Normally, when wiring, I just drop both nodes and then wire from terminal to terminal. I am pretty sure that it is impossible to just create a tunnel on a structure; unwired tunnels typically are removed by type prop. I think that the wiring scripting methods were not created with "bad wiring" in mind. My guess would be that you cannot create a loose end through a wiring method, but rather like you would on an actual diagram, like you discussed.

Yair is correct; actually, all the responses look good.

I believe the answers to your questions are Yes and No, respectively. Under the hood, I believe the property node is decomposed into an actual in-place element structure. Property Nodes for by-value class wires I believe are decomposed into standard method calls and so would generate no additional errors. I'll forward this to the developer to see if he has any comments.

Yes, for automatic dereferencing you need at the very least an input/output pairing of VI terminals where runtime type is preserved, like in dynamic dispatch VIs. We have talked before about having an "in/out" or "inplace" marker on the connector pane. The real problem with this feature however would be error handling. When you dereference a reference (DVR or any other type), you can run into errors (the reference could be closed or was never good, etc.). You will notice that most nodes that take in references also have an error out terminal. Dereferencing a DVR can definitely produce errors (not to mention the fact that the access is asynchronous potentially and this would be hidden from the user) but static methods have no error terminals. There would be no way for us to pass errors along either to the static method itself nor to the callee; instead of getting the actual class, they could get a default data instantiation of the class and be none the wiser. This is why the property nodes will auto dereference; they have error out terminals.

Also, LabVIEW manages memory for you, so you (typically) don't have to worry about passing everything by pointer or using pointers to allocate, etc.

On that note, LV R&D is collecting info to further improve edit-time responsiveness. We'd appreciate everyone who has the time to fill out this survey: http://bit.ly/aWBf1j