Leaderboard

You have to disassemble the Variant. One option would be a Variant Tree indicator. To get the actual values you can use the OpenG Variant Data tools: Ton

Like this? http://screencast.com/t/jGDycjpVm Go here https://decibel.ni.com/content/groups/labview-apis/blog/2013/04/01/for-loop-pass-through-utility

Name: Wire And Connect Quick Drop Plugin Submitter: bbean Submitted: 03 Apr 2013 Category: *Uncertified* LabVIEW Version: 2012 License Type: BSD (Most common) This Quick Drop (QD) plugin complements the functionality of the built-in QD plugin (CTL-Space-CTL-D) by wiring between selected controls, indicators, constants, and SubVIs. Default Shortcut - [W] Normal Operation Wires selected nodes in left to right order. Attempts to connect any common unwired terminals in between the far left and right nodes by checking the datatype, Name, or Caption. Holding Shift and the Shortuct: Wires controls to unwired far left Node terminals and indicators to unwired far right node terminals. This is just something I put together as my first attempt at a Quick Drop plugin. Something similar has been done previously to wire the corners of subVIs using the right click framework by user JCC_(SK): RCF Plugin - Wire Nodes by Corner - https://decibel.ni.com/content/docs/DOC-8386 . Code for this plugin was developed prior to knowledge of the JCC_(SK) RCF code and probably doesn't function as well since it hasn't been tested thoroughly. However this plugin is for quick drop and has some added capability to wire up all like terminals but can suffer from potential overzealous wiring. Just delete extra wires if necessary. Thanks to the NI guys for creating the QD template with good instructions. Someone may have done this already but I'm putting this out for comment anyway. http://www.screencast.com/t/PZhMafM2 Click here to download this file

I assume that the panel color 0x01000037 is not sufficient? Ton

I don't know if I am one of those you are referring to as arguing "everything should be public," but I don't think I made that claim at all. I assume you're referring to Shaun. I have claimed that putting restrictions on a function reduces it's utility, which I loosely define as the number of places the function can be used successfully, but that's not the same as claiming everything should be public. There are definitely some elements in your argument that contradict my interpretation of the straitjacket's purpose, and given my interpretation the conclusion doesn't follow from the arguments you've presented. By and large I agree with a lot of the stuff you say in the post, but I disagree with your conclusion. Trying to suss out the specific areas of disagreement... This is the most obvious place where our understanding of straitjackets differ. First, whether the requirements are embedded in source code or applied via an external file isn't the important question in this discussion. The important question is, "who is responsible for declaring and applying the restrictions, the code author or the code user?" The mechanism for declaring restrictions can't be decided until after we figure out who is able to declare them. Second, the nature of the restriction isn't important. A restriction is a restriction. Labview allows us to declare certain kinds of restrictions (input types) and doesn't allow us to declare certain other kinds (execution time.) For this discussion let's assume all restrictions are declarable and verifiable. In the statement above you're setting up a straw man. No useful code can have *no* restrictions, else it doesn't do anything. As soon as you define something the code does, you're also implicitly defining things the code doesn't do, and that is a type of restriction. You go on to give several examples showing where the code author implemented the correct amount of code checking. In all of these cases he had knowledge of the environment where the code is going to be called and could set the restrictions accordingly. This is also where your argument starts to go astray, imo. In the math function example, the author chose to include array checking inside the function. That is a valid design decision, especially if he has complete knowledge of the calling context. As it turns out, he didn't have complete knowledge of all future calling contexts where someone would want to use the function, and, because he included array checking as part of the function, it couldn't be used in those other contexts. The built-in array checking prevented someone from using the exact behavior that function provided simply because it didn't meet an arbitrary requirement. He could have let the caller be responsible for array checking prior calling the function. That trades away a bit of convenience in exchange for increased utility. He also could have written and exposed two functions, one implementing the basic operation without any checking, and another that checks the array and then calls the basic operation. That slightly increases overall complexity to get the utility gains. Was he "wrong" to include array checking in the function? No, not at all. Did it reduce the function's overall utility? Yep, absolutely. Where he was "wrong" was in his assumption that he knew all the contexts where the function would ever be called. Would prior knowledge of the other context been sufficient justification to change the design? I don't know... that's a subjective judgment call. But it did have real consequences for someone and I don't think anyone would argue against him being better prepared to make a good decision if he is aware of other contexts that people might want to use the function than he is by assuming those contexts don't exist. What you're saying here is a little different than what I remember you saying before. Before you claimed the parent class should have the ability to declare arbitrary restrictions that all child classes must adhere to, because the calling vi might wish to establish some guarantees on the code it calls. Here, you don't explicitly say who should declare the restrictions. Are you still maintaining that all the contractual requirements between a calling vi and a callee parent class should be declared in the parent class?