Leaderboard

I need to get an instance of a class that I know will be loaded with my application, but "Get LV Class Default Value" seems only to work with a full on-disk path to the .lvclass file. I tried passing in a string with the fully qualified name of the class, but it gives me error 7. Is there a way to get an instance of the class on my block diagram by referencing it in memory? (This is for a generic object deserializer, so I can't simply drop a constant of the class on the block diagram.) (No, I'm not trying to reproduce AQ's work in the other thread on serialization. Although the VI I'm writing is generic, the serializer is mostly special-purpose.)

Excuse me while I vent, but I can't be the only one in this situation. Let's see if this sounds familiar to anyone, as an exercise we'll play a follow along game with how to add a control to an existing class: Open the class' .ctl file. Drop the new control in the private data cluster. Wait... Does LabVIEW recover? If no, kill LabVIEW.exe and start again at step 1. Rename the control so it has a proper name. Wait... Does LabVIEW recover? If no, kill LabVIEW.exe and start again at step 1. Save the .ctl file and move on. This scenario has become all too familiar on a large project I work on, let's just say there better be a damned good reason for me to change any of those classes (and honestly, it's not that "big", it's just "LabVIEW big", maybe 1600 VIs). But I also have a much smaller project with maybe 18 classes (~250 VIs) and the inheritance hierarchy is at best, three levels deep. And now LabVIEW sees fit freeze indefinitely when I drop a new control on one of my classes. Don't get me wrong, I love OOP in LabVIEW. Frankly, without OOP I would have relegated the language as a relic of the past and moved on long ago. But I'm getting a little tired of not talking about this dirty little secret. OOP is great, but it's not all sunshine and lollipops, there are some serious gremlins creeping around in there. I've been trying for over an hour to add a DBL to one of my classes and still no luck. Seriously? Come on now. Mass recompiled my project? Check. Flush my object cache? Check. Surely this happens to others?

I would suspect it is a “Root Loop” issue. I know that Open VI Ref can require LabVIEW’s Root Loop, and this loop is blocked by the User opening a menu. Perhaps a LV dialog also blocks root loop? BTW, if it is Root Loop, then a method used to get around this problem is to use a single reference to a pool of clones to do all asynchronous running of VIs. Then the ref is only acquired once, before any action that blocks root loop can happen. The latest Actor Framework’s “Actor.vi” is an example of this.

You need few packages, OpenG and JSON Labview, both available from the code repository here, or better yet, via the VIPM.

Not sure what you are asking here, but KML has the ability to define the colour of a polygon (or line). The polygon is defined by map coordinates Here's a simple example that I found by Googling that enables you to turn on and off a coloured KML overlay.

LabVIEW is just the host. You need to create a KML file then get Google Maps to load it.

Interesting. We are still on LV2011 and will remain so for another month or so. I've spent quite a bit of time de-coupling my application in an effort to make it more editable. Basically I now have an application level project which defines the entire scope of the application, bringing in each component such that the run-time entity can be defined. Then a bunch of individual component level projects for working on each part by itself. If you look at the dependency tree for a component level project, each has some common framework ancestors as dependencies, the core application level object, and then whatever else it ends up using as it goes about it's business. With one exception no component is aware of other components. In some situations it has helped, but not others. Some classes remain un-editable in the larger application level project, the process for working on these classes is tedious at best: Open the component level project to perform editing. Save. Close project. Open the application level project. Run, debug, identify problem. Close project. Open the component level project to do more editing. Save. Close. Etc... Fortunately this process only really needs to be done when some fundamental changes are being made to the classes. I never try to change the private data clusters from the application scoped project for any class. Deleting or renaming VIs can (but not always) throw LabVIEW into a tizzy. Generally editing an existing VI is fine, though you need to step into a cadence where you make an edit then wait for the compiler to catch up. What I wouldn't give for an option to have LabVIEW wait to recompile until the UI idles for a few seconds. Yes it takes me 30 seconds to wire up a VI because I have to wait. After. Every. Wire. Or. Constant. I. Drop. A few minutes of that usually ends with me closing the application project and going back to the component project only to switch back a few minutes later. In the end though, I've actually learned a lot from all of this. I still don't know exactly why it happens, but I have learned a tremendous amount when it comes to large application development in LabVIEW. Over the years this project has grown so much and I am a far better programmer now for having to had tackle these challenges. For all my criticism of LabVIEW, I still love it.

I don't think anyone is doubting it happens, but for the record here's a video I made a few days ago when this issue crept back up to the top of the lava feed (no idea how to embed it). http://www.screencast.com/t/e8szIGbKRz Doesn't show much, just that it happens. I sped up time during the video, but it was a few minutes of me trying to add a numeric control to a class. Got so far as to add the control and attempt to change the name. I had to kill LabVIEW.exe before I even got a chance to change the control to an I64. By the time I produced the video I had let the IDE spin for about 20 minutes before killing it, but I've let it go overnight before and it has not recovered. The ridiculous thing is when I went and edited the class alone, I then went back and opened up the original project and everything just worked, no big recompile times once it had to load the modified class. This is fairly typical when this happens. The class in the video is very simple: it has no VIs except accessors, all are static and available through property nodes; not involved in any inheritance chains (except LabVIEW Object); and I'm pretty sure none of the fields are objects so it ought not to have any class dependencies.

For the Discovery Channel Telescope software, we make extensive use of libraries and classes. We never have this issue when editing classes. Perhaps what helps make this possible is 1. Programming to an interface, not an implementation: Abstract classes with pure virtual methods separate almost every call layer. 2. For each software component we do development work within several small lvprojs (with few dependencies), then only one large project from which we do builds but typically no development work. 3. Architect to avoid overly-complicated dependencies.

I have experienced this a lot in the project I am working on. At first I thought it was something I was doing wrong. now that I found this thread and the discussion in the AF community, I realize that there is something going on with the IDE. I continue to have my classes in lvlibs. The architecture I am working on has multiple QDMH with their messages wrapped in classes. Not as fancy as the Actor framework but it gets the job done. I like to have the messages inside the lvlibs. So, my workaround has been: Remove the class from the library save Disinherit the class save modify private data wait for LabVIEW to take its time (if it is too long for my taste, couple of minutes, then I kill it and try again). modify accessors/property nodes save inherit again move back into lvlib some times I don't have to kill LabVIEW at all, other times I have to. I have even gotten into a situation where I have two machines working in parallel and see which one can do the modification without choking. Even after all this, I won't give up on using classes nor lvlibs. I like the project organization, name spacing and dynamic dispatch too much. But I wonder if I would be so optimistic if my project was larger. Glad to know I am not the only one. I hope Fabric's idea gets a lot more kudos. Fab

Hi, We have been doing code reviews QCP's (quality Peer Reviews) for a long time now on all our "new" software and "software changes". Our process is based on one we use site-wide for C++, C (30 + develpers) and LabVIEW (6 developers). I have uses this same basic process for many years at different compaines It is done as a formal traceable process, built into our own web based tools that we use to control ClearCase our source control tool. The web based tool we created and use acts as a both records keeping system, who was the reviewer, log of review comments (and developer responses) and process machine, controlling when a QCP (quality Peer Review) needs to be done. When do we do a QCP All software written, bug fixes /new features and carried out on separate ClearCase branches. Each ClearCase branch is atomic, ie it contains all the changes for that bug fix or whatever. The developer tests and codes on that branch and at bthe point the developer is happy that the code is ready to go into the ClearCase mainline (ie ready for everyone else to use or be released) a QCP will be done. So ALL software is peer reviewed before it is added into the main code stream, this is control by our web tool which will not allow a merge back into main until a QCP has been passed. Note a branch could have one file on it or lots. Typically a branch is kept small in scope, even for new major new software we would try to built it up a bit at a time with a different branch for each bit. This is partly to make the peer review of a branch more manageable. In LabVIEW we only really get big branches when we have major recompile issues. A branch status goes : development - ready for QCP -- passed QCP (or back to development) QCP levelsOK we all live in the real world and not all software changes are equal, plus sometimes pragmatic decisions are needed, "FIX THIS NOW" so we have some different level of QCP that are carried out. Our QCP levels are None - very rarely used level , must be accompanied by a good reason for this type of review, maybe a save due to recompile only Maint - just a quick check over the changes made. High - examine the changes made and their context. Detail - same as above really possible we do not need this option Demo - show the review the change in action The key here is that, the information is recorded (so traceability) the developer has to think about it. I would say that 99.9% of reviews are done as high /detail What happens in a review First off, during a review it is the developers responsibility to satisfy the reviewers comments or questions, after all it it the review that passes or fails a QCP. If a QCP passes then the code is merge into the mainline and the branch is closed. If a review fails the branch goes back to a development state and the developer needs to address all the reviewers comments. A reviewer will do the following for all reviews except the None type. 1) Load all the top relevant top level VI's and ensure that a) there are no broken run arrows b) they close with no save's needed. 2) Run the VI analyser on all the files on the branch. We have this automated and the analyser config spec set to our custom requirements. All failures will be visually examined. We have a document which deals with the analyser results, which must be fixed / which should be fixed (or explained away) which we can ignore and in what circumstances. We use the VI analyser as a style guide tool. 3) The reviewer will use the OpenG compare to disk tool (modified to work with LabVIEW 8.2) to visually look at the code changes between the current version on main and the ones on the branch under review. For a high / detail review (our normal review type is high) the review will also look at the wider context of the changes and how they fit into the general scheme of things, how they meet the requirements of the change or bug fix. Any comments the reviewer makes are logged. If the reviewer is not happy with the code the branch is set back to development status, the comments are mail to the developer who must then, explain / justify a code change or modify the code. Being a smallish team, often the reviewer and developer will sit together during a review so typically when a review has failed the reviewer and developer have already agreed on what corrective action is required to pass next time, but the comments and reply's are always recorded. Following a failed peer review, the developer does their changes and any retests again (weell the code has changed) and then resumits the changes back to the original reviewer for a new QCP, hopeful it will pass this time :-) Other comments I would like to get some automated unit testing built into this system but it is a while before that will happen. Having done QCP's for many years, I can honestly say Iwould not develop software in ANY language without a peer review process of some sort. The value of getting somebody else to view your code cannot be over stated. Just from a simple style point of view if nothing else. When you KNOW somebody else is going to look at your code with a critical eye you tend to write your code differently. Nearly every code review results in a valid comment that will improve the code, this is NOT to say the the original developers was poor or lazy, just a different view is taken by the reviewer, in some case our peer review has stopped code going into our mainline that would have been a major problem if it had got released. Finally, I did see a really good NI webcast Performing Technical Code Reviews to Improve LabVIEW Code Quality but though I found a link to it at the bottom of the page it seems to now be removed I hope this makes some sense and is of some use cheers Dannyt