crelf

Works for me - can you try again? Also, what's the url of the download that you're trying? And what's the url of the page?

Ooooo - pretty...

Admit it: You still want to rewrite it...

I can't speak for anyone else, but if I'm trying to change the output of a sub vi based on how (or if) downstream code is using it, that's a pretty good indicator something is wrong with my design.

I don't agree - for exatly the reason that the original class primative was written this way: it has 2 functions: cast the class, and error out if you can't - using it without caring what the new class is out but only being interested *if* is can be cast is a perfectly valid use case in my opinion. I'm not saying that this is a technique I can think of using often, but it'd be nice to have it in my toolbox.

If I'm understanding correctly, you just wrap your heavy-lifting code in a case structure that uses the sentinel value as its selector. I think that would be enough for LabVIEW to know what's up.

Which is the same as I said with a ring selector - which is fine, as long as it's a required input and you you remember to change it.

There were a lot of links broken in the move - if you see them, mark them by using the "Report to Moderator" link on the post, and we'll try to sort them out.

Let's add a philosophical question. Assume you know the truly correct answer, and that it is different than the one you assume NI is looking for. Do you mark the correct answer on principle and lose the points, or do you choose the answer NI is looking for?

That depends on your aim: to be correct, or to acheive certification.

Have you looked at the OpenG type descriptor VIs? You might find something useful in there...

...but what about the use case that spawned this thread: not doing a bunch of extra work if the output of that work isn't even wired? Any ideas on how to do that at teh subVI level? I guess there could always be a ring where the programmer could just select what they do and don't want done, but if only the subVI was aware and could make that decision itself...

...rejected since inlining doesn't prevent a VI from being used with the Call By Reference node. Also, very large VIs should not be inlined, and there's a real probability of people turning on inlining on something big just to get a feature like this...

Very true - that could certainly mess a bunch of different things up.

...could still be better achieved by making it part of the function's signature or making a new type that has sentinel capacity (i.e., a class that has a boolean for "is initialized" and then the rest of the data).

Please talk about that a little more - your post refers to another post ("as described by mechelecengr above") that doesn't seem to exist any more.

See this - http://forums.ni.com...is/idi-p/926281

So the answer is "no", because:

Users have three existing options to solve this problem:

1) A sentinel value (as described by mechelecengr above)

2) If all the values in your range are valid values, create a cluster of the u8 and a boolean and use the boolean as the sentinel value.

3) Create a poly VI that has a junk type (perhaps boolean) on the first implementation listed in the polyVI and and the desired type (u8 in your example) on the other implementation. If the u8 is wired, LV will call the version where it is assumed the input is wired. Otherwise it will call the other, which is written to assume the input is not wired, which may be way more efficient because the runtime system doesn't even have to test anything.

Your request for this "is wired" property is a feature that I explicitly asked for early in my time in R&D. I learned that it is a bad idea because pretty much any proposed solution that we could do in the LV compiler would be LESS efficient than what a user could code on the diagram. To begin with, the Invoke node itself causes the FP to be loaded into memory in order to have anything to reference. That slows the execution of a subVI considerably right there. More, because we wouldn't know whether a given terminal would necessarily be asked for its "is wired" status, and because there is no block diagram for VIs in the runtime engine, every caller VI would have to compile into itself information about whether or not optional terminals were wired.

We can do various things like say "this method can only be selected on an implicitly linked Invoke node", which lets us flag callers of subVIs that they need to compile in "wired or not" records into themselves for particular subVI terminals. But that creates problems for Call By Reference nodes since something that had the "this terminal will be tested for 'is wired'" would have a different conpane signature from an otherwise identical conpane that did not test for "is wired".

In the end, this request is not really supportable by subVIs. Built-in functions can do it because they generate all of their code into the caller VI. Even if we someday have inline subVIs, this would require special code that told LV which portions of a diagram to inline based on whether or not a given terminal was wired -- probably a new structure node or something like that.

So, short story:

Yes, this has been contemplated extensively by R&D over the years.

No, we're not likely to do anything to implement this feature or anything similar to it.

We have Inline subVIs now

Write your own compiler.

That's all I need to do?!? Sweet!

Actually, what I'd like is just to know what inputs and outputs are connected to a subVI - that would be super sweet. Maybe I should post it over on the idea exchange.

"The Property nodes contained in a SubVI always cause the front panel to be loaded in memory" is False. Am I right?

False is correct.

Awesome topic! Good to see such a thread where everyone is playing nice and actually debating technology features, not marketing-based emotions

PS: My original thought where why would you buy a tablet when you could have a smart phone? The only IMHO valid retort to that was someone wanted an eReader - and my response was that, if the only valid reason to have a tablet was to read books, then get an eReader - ePaper is simply amazing: I couldn't imagine reading a book on a tablet for a couple of hours verses using an eReader (my wife has a kobo, and it's awesome).

So I guess I still haven't found a compelling reason to pay for a tablet. Except for

It depends on the type of property node you're talking about - there is no blanket yes or no answer to this. Darin's tight - check the context help for hte properties you're interested in.

A question from the twittersphere:

if i run a subVI containing a property node, is always the subVI front panel going to be loaded in memory?

Hey Crelf, this Toolkit is great! Far more easier than the standard build in XML toolkit. Not 100% sure about the price, but thanks for the heads up anyway.

Isn't it neat? I was coding something similar up myself once and got annoyed with how long it was taking to write a generic parser - talked to Jim about how EasyXML works, and BAM! It's one of the most over-looked toolkits, IMHO.

I either have the tasks built in the project explorer or manually create them in code.

Depending on what I'm doing, I prefer to create tasks in my project - then I have something other than a MAX nce file to work with should I need to come back to an old project. It's another feature that a lot of us forget about.

I attempted to reply over on the NI forums, but there's something broken there at the moment, so I'll reply here:

We've taught the To More Specific node to be aware when its output is unwired and not tell the compiler that it modifies the input object. That means that the first "To More Specific" just does the type testing and never modifies the object even if the cast fails, so the original object remains available for the case structure. The second "To More Specific" actually does the cast.

That's a super neat thing to know. But it leads me to the quesiton: how can I do that in *my* code?

Could be because of the GigE cameras communicating over ethernet - the protection might be considering some of those communications as suspicious and is scanning them for yucky things?

Awesome - welcome Jason! It's good to have you on the team.

What I would do is create a config file using the standard XML format. This would be originally created from a TypeDef cluster containing all variables (this is also a good idea because it is expandable if required). LabVIEW contains XML subVis which can be used for this config.xml file. Make sure you specify labels for each element in the TypeDef cluster, as they are required in the XML file.

I agree - and if you're working with XML, you need the JKI EasyXML Toolkit. Seriously. Need. It's awesome. Why are you still reading this post? You should be downloading the EasyXML Toolkit demo. Go do it. Now.

They can only legally be distributed to people who have signed some usage limitation documents with NI - If you're certified, you will have already done that, and should be able to access the files on ni.com. Otherwise, I'd try asking someone in the Training group at NI.

All my work and personal computer are MACs, which I love, and I paid the price by trying to diversify.

So anything other than mac products are crap? I guess Steve Jobs' marketing techniques worked.

I'd suggest you get a smartphone instead - something like a Droid X2.

It's just a very well-controlled flame.

Exactly!

Did anyone else find the 4 second video less than satisfying?

Only if it wasn't looped.