Leaderboard

How about this? Use the Control Value Set method to pass data to the controls and then run the VI with the wait until done flag set to false. It's particularly easy with classes because all of the current values of the class data get passed with one call the the Set method. Mark

You are almost there. All you really need to do is add logic to find the end of the patches and subtract indexes (see lower half of snippet). Note: If the data ends in a thin patch, you will not get a length out for that patch without some extra logic after this loop.

Hi Jonathan, I don't know which solution you chose, but I meant to put this example together earlier... just didn't find the example code I was looking for. The code below is taken from John Lokanis, see this topic. Anyway, I put up this example. playing with Make Window Transparent.zip <object id="scPlayer" class="embeddedObject" width="1090" height="628" type="application/x-shockwave-flash" data="http://content.screencast.com/users/normandinf/folders/Jing/media/ce6b4f99-a9d6-40d3-812d-4a21bc6d3f07/jingh264player.swf" > <param name="movie" value="http://content.screencast.com/users/normandinf/folders/Jing/media/ce6b4f99-a9d6-40d3-812d-4a21bc6d3f07/jingh264player.swf" /> <param name="quality" value="high" /> <param name="bgcolor" value="#FFFFFF" /> <param name="flashVars" value="thumb=http://content.screencast.com/users/normandinf/folders/Jing/media/ce6b4f99-a9d6-40d3-812d-4a21bc6d3f07/FirstFrame.jpg&containerwidth=1090&containerheight=628&content=http://content.screencast.com/users/normandinf/folders/Jing/media/ce6b4f99-a9d6-40d3-812d-4a21bc6d3f07/transparent%20panel.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/normandinf/folders/Jing/media/ce6b4f99-a9d6-40d3-812d-4a21bc6d3f07/" /> <iframe type="text/html" frameborder="0" scrolling="no" style="overflow:hidden;" src="http://www.screencast.com/users/normandinf/folders/Jing/media/ce6b4f99-a9d6-40d3-812d-4a21bc6d3f07/embed" height="628" width="1090" ></iframe> </object>

I just did a search...those methods are not used anywhere (including the Property Pages) in LabVIEW 2010. I have an educated guess as to their purpose, though. Back when the Property Pages were first added to LabVIEW in version 7.0, there were many properties of VI objects that were not yet exposed in VI Server. As a result, the Get/Set Object methods were added, and hard-coded indices to an internal database of properties were used for getting/setting properties of controls. As the VI Server interface to objects improved, this mechanism was no longer needed, as evidenced by the fact that the Property Pages now (in LabVIEW 2010) rely entirely on VI Server to get/set object properties. -D

OK, now I have some experience with this feature and my experience has not been so good. First the good news: you don't get dirty dots all over the place when you change a typedef. Yay! Also VIs are (a little) smaller. Yay! The bad news: The converter tool in the project doesn't work at all, but you knew that. It makes building an application slower and less reliable. I'm not sure how much of the speed reduction is just the (more complex) LV 2010 compiler, but it takes just under 2 hours to build our product now vs about 50 minutes under LV 2009. Sometimes the builder stops working (stuck on build dialog using %0 CPU, forever), or throws a bogus error about how a "a bad VI cannot be saved without a block diagram" when in fact the VI is OK. Nuking the object cache and allowing LabView to rebuild it will fix the bogus error message, although it can come back if you build multiple products. Going through the source tree and removing busted stuff that isn't used in your application but is referenced in a library (or a referenced in a library that is referenced in a vi that's in a library that's in a vi that's in a library...I hate this behavior or libraries!) seems to help. Things can get COMPLETELY messed up if you revert your working copy in subversion. I moved a typedef into a library with only the library open (vs all of the source code), which turns out to be a bad idea because LabView can't figure out that "mytypedef.vi" at mypath is the same as mylibrary.mytypedef at mypath. Well, OK, I can sort of understand that, so I reverted the whole thing and pulled everything in memory so the linking would propagate. Total mayhem ensued. A whole bunch of callers now believed that mytypedef was still in mylibrary, even though (since I'd reverted) neither mytypedef nor mylibrary believed this to be the case. Trying to fix it manually by selecting the VI from the file dialog (like it asked me to do) resulted in the attached error message when trying to save the caller. Yikes. The problem was that although I had reverted the source code, there was still some object cache sitting around from mytypedef's short excursion into library-land. At this point I just wanted my code back, so I quit LabView, trashed ViObjCache, reverted everything and started over. That seemed to fix everything. I say "seemed to" because I found one block diagram constant of the typedef in question was sitting at value = 0, where it used to have value = 18. If you opened it directly from the windows explorer, or opened it with the vi server and then made a cosmetic change and reverted it (even though it was just loaded from disk and no changes had been made!) it fixed it. Trashing the object cache before launching LV also results in the correct value (18). But if you just used it (and there's no reason why I should ever look at it, given that it has not had a "real" code change in several years), the value of 0 was used. If you saved it or exported it in that stage, the bad value becomes permanent. Needless the say, the thought of LabView changing block diagram constants is pretty terrifying. We've never trusted cluster block diagram constants (that's a hard problem, updating the constant when the cluster is changed), but you'd think an atomic type (a U16 enum!) could not get screwed up in this manner. Well, I don't know exactly how it can happen, but it can happen. Yikes. I'm working with NI on this, but it's difficult to reproduce because any change to the vi (like moving it to the app engineer's computer) will generate a new viobjcache that won't be corrupt. So I don't really know where to go from here. I've loved not having recompile-only changes that interfere with reasonable use of a source code control system, but the thought of block-diagram corruption is extremely worrisome to say the least. I've been thinking more about the potential problems associated with reverting a file in subversion without reverting (or deleting) the relevant file in the VIObjCache; it's actually a hard problem from LabView's perspective, because things have changed without them necessarily knowing that they've changed. I don't know what algorithm NI is using to determine whether obj cache file is up to date or not; it seems to be pretty good, but it's not perfect. Next time I do any big-time reverts (that includes major typedef changes, for example), I'm going to quit LV and nuke the object cache. I'm not sure what to do with the more common let's-just-revert-this-back-to-the-current-revision revert; blasting the whole vi obj cache will really increase the overhead of doing that. Maybe we'll just go back to bundling the object code and source code, since then they at least get reverted together. I'm not looking forwards to that, but it beats having Labview corrupt my code.

It's been tough going through the last month without our beloved LAVA site, but behold, it's back and better than ever. We're calling this version LAVA 2.0. Welcome back! How did we get to this point? Well, there was a serious crash on the LAVA server database and years worth of data was lost. I didn't have a very good backup and data recovery process in place, which meant I couldn't bring the site up the way it was before. There is good news however... keep reading. Just to step back a little to discuss the history of LAVA. LAVA started back in 2002 as an experiment by myself and mostly to provide a web based platform for LabVIEW discussions that could be on the same level as the then popular Info-LabVIEW mailing list. I wanted to host quality discussions where the tiniest detail and minutia of LabVIEW coding could be discussed at an advanced level using the latest web technology. Well, it was a slow start but after a few years it looked like LAVA was a hit. The member levels grew and along with that, more stress on the server and site. Throughout the life of LAVA I was the sole administrator of the back-end system. I managed my own server and performed custom modifications to the forums application framework. However, this could only be sustained for so long. I have a "real job" of course and spending time on LAVA administration is on an as-needed basis. So, after a few months of neglect and a few careless server maintenance actions on my part, the inevitable happened. Data was lost. I didn't know what to do at that point and decided to tap into a few trusted LAVA members and friends for help. Jim Kring and justin Goeres to name a few. It was decided that a more decentralized management of LAVA was necessary to avoid another catastrophe and allow more people the ability to manage and help with the workload. We also took this opportunity to experiment with a hosted community service called Ning. The Premium members and some key LAVA members were invited to try the site out for a week. That went ok at the start but we found that it lacked the power that LAVA users were acustomed to. We also had an issue with how much control they had of all the site data and with how limiting the system was to modifications. At the end of the day we concluded that it would serve the community better to keep the familiar experience of the original LAVA intact. We scrapped the Ning site and took what we learned to relaunch LAVA. Here's the good news part. It turns out I had an off-site backup of the data from Feb 2007. Also, it just so happened, that avid LAVA reader, Philippe Guerit, was keeping all the RSS feed content on his computer since after Feb 2007. What luck! Buy the man a beer! I've managed, using LabVIEW of all things, to extract the old database data. Jeff Plotzke wrote a program to parse through Philippe's RSS feed file. And together we were able to get all the old content imported (yes, the dreaded Alpha thread too). Chris Relf and Mark Balla have also worked hard to manually import the old CR code into the new site as well. That data had to be manually imported. The bright side of this restructuring is that now I have more people to help out in keeping LAVA alive. We now have 6 administrators instead of just one. We have moved LAVA to a hosted Invision (the company that makes the forum software) server account, making it more reliable with regular backups. I have found a new friend in Jeff, who knows PHP, (why didn't you say so a long time ago?). And I have learned how to ask for help I want to assure you that all of us who have worked on getting the site up and running are passionate about keeping LAVA alive. We hope that you welcome the new LAVA, along with some of the new cool features we've added, back into your daily workflow. I'll be creating a separate topic to describe some of the new features in LAVA 2.0. In the meantime, please post any questions or problems with the site here. Note that the only way to login to your account is using your email address. To get a new password click the forgotten password link and fill-in ONLY your email address. Thanks to Jim, Jeff, Justin, Chris, Mark, Philippe and all the Ning beta testers.