Leaderboard

When working with dynamic code, sometimes we end up with a generic reference that we need to cast to complete our operation. Example: You make a sub-VI that extracts the plot color of a waveform chart or a graph. The reference input to that VI must be of a common reference type (GraphChart) The problem is that this property, although it exists for both types of references does not exist in the common type. Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/d223f6b4-83a2-43dd-a830-be17877c9715/2010-09-10_1849.mp4 So if you want to have a piece of code that can operate on both types of references, what do you do? Somehow you need to have a switch in your code that will conditionally run the correct code based upon the specific reference you wire in. The way some people do this is by utilizing the 'Class Name' property into a case structure but this has problems w/ flexibility Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/9f771182-303a-40d2-96db-3701ee43ff7f/2010-09-10_1903.mp4 This is a simple case where there is only 1 or 2 sub-types. What about a numeric w/ all of it's myriad of sub types (slider, guage, etc). The appropriate way to handle this is by doing a type cast, but people typically solve the 'Many Cast' design pattern VERY POORLY through nested error structures. Which looks really ugly Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/7c0e0bfe-966a-458a-8bc8-c44bf6a91cc5/2010-09-10_1913.mp4 So what is our alternative? Introducing the very useful, and practically perfect in every way 'Many Cast' design pattern. It's stackable It's scalable And it even tosses errors properly Proof: http://content.screencast.com/users/NJKirchner/folders/Jing/media/55e8e391-bb10-4cc2-9a15-2e2a46912bb6/2010-09-10_1933.mp4 The Code is attached, not as a package 'yet' Demo to Follow in the subsequent post Design Pattern - ManyCast.vi

Darren Nattinger (he of Darren's Nuggets fame) and I need your help. Darren is known for writing useful VI plug-ins for LabVIEW. I've had a history of creating hooks in the C++ code for calling plug-in VIs. He and I both dislike the current behavior of the Create SubVI From Selection feature. It doesn't know about the config token for preferred connector panes, it doesn't put error terminals at the bottom and class/refnum terminals at the top, it sometimes names a control "error out" and an indicator "error in", and the panel isn't laid out as clean as we might like. These are all things that could be fixed in the C++ code, but spare developers are always hard to come by, and Darren already has some G code for doing this work. Thus it made sense for the two of us to work out an interface from C++ to G to improve Create SubVI From Selection. In our spare time, we've found the right place in the C++ code to hook, figured out the data that needs to go across the interface, and gotten the code pretty close to finished. Once we knew it was going to work, we asked for permission to add it as a feature in 2011. That's where we hit a problem we cannot solve alone. As many of you have heard, LabVIEW 2011 is focusing on being a stabilization and performance release. Very few new features are being let in the door. The one gate that new features have is the Idea Exchange. The feature has to be limited in the amount of code it has to touch. It has to avoid performance degradation. And it has to be something customers clearly want. We can show two of those three requirements, but not the third. Without the third, the feature does not meet the goals for LV 2011, so even though Darren and I have the new callback hooks largely ready to go, the code cannot go in. This makes us sad. I mean, it makes perfect sense -- we have to have standards, and limiting the features for this release is important -- but it still makes us sad. "Create SubVI" is an area of LabVIEW that many of you have asked me about over the years, hoping that LV could do a better job. Darren and I really want to see this feature go into LV 2010, and we're pretty sure that there are enough of you out there that would like to see it too. If we could get the Kudos on the idea up so that the idea is in the top 15, we will be able to make the argument that this is a feature that users strongly want. Now, not every idea with high kudos is automatically blessed in the 2011 release, but with enough Kudos, we think we can get permission to proceed. There are 3 ideas on the idea exchange that are all affected by this idea, but let's focus on the one that has the highest kudos already: Create a proper connector pane when doing Edit -> Create subVI As of right now, that's got 79 kudos. To make it into the top 15, we need 160 kudos, or almost exactly double what it has right now. I think this is an idea whose time has come. If you agree, please contact your friends. Make peace with your enemies. Call your mother. Encourage them all to take a moment to go vote for this idea. If you're super ambitious, there are two other related ideas that would also be aided by our feature. You could go vote for them too. But focus on the big one first! Provide a way to define the default connector pane Edit >> Create SubVI: Tweaks Help make Mercer and Nattinger unsad! Help improve Create SubVI! Vote now!

SO.....Dak, the problem is that it is functionally different. Check out the second video again. If someone made a piece of code that only had String Name case structures for ClassName WaveformChart & WaveformGraph, their code would fail to execute anything if those were the only two cases handled EVEN THOUGH the WaveformGraph case could have handled the XYGraph just fine. Shaun, I agree that having the Class Available in the case selector would be better and maintain the robustness and flexibility of the pattern, but that requires a new type of stacked frame structure in LV to exist outside of a feature request No, I'm saying w/ the design pattern, you don't have to make a special unique case for the XYGraph at all because the cast to WaveformGraph will not fail. But as you've seen, not all common properties in class trees are common Excuse me?? What?? Um, U B mistaken sir. XYGraph is a child of WaveformGraph Thats assuming that you're trying to access properties and methods that exist in all cases for the common ancestor You give me far too much credit sir. Working in the tower has it's perks, but not the midas touch of LV wisdom. Although easy access to the 3rd floor is damn nice. SO.... this gets to the heart of your argument and the weakness in my example. I stand by my example as a good simple case of showing why the string based operation fails and if someone was trying to make some generic code for waveform graphs they would easily miss the XYGraph case and need to go back and re-code BUT!!! Where this code really shines is while doing LVScripting, where you end up with an array of GObject often and need to operate on a variety of types which a common ancestor with the needed functions can not be assumed or found. EXAMPLE: <object id="scPlayer" class="embeddedObject" width="944" height="566" type="application/x-shockwave-flash" data="http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/jingh264player.swf"> <param name="movie" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/jingh264player.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/FirstFrame.jpg&containerwidth=944&containerheight=566&content=http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/2010-09-11_1240.mp4&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/"> <video width="944" height="566" controls="controls"> <source src="http://content.screencast.com/users/NJKirchner/folders/Jing/media/4175933d-db01-4105-b527-c9935b5bc59f/2010-09-11_1240.mp4" type="video/mp4;"> Your browser cannot play this video. Learn how to fix this. </video> </object> By all means, keep using the 'Class Name' based selection of your code, but I believe you will find that, although it potentially meets your needs immediately, you have introduced a point of weakness into your code that unnecessarily would need modification to handle cases not originally though of. But why would you?