Omar Mussa Posted April 25, 2007 Report Share Posted April 25, 2007 I just finished the first phase of a project where I'm using 15 different LVOOP classes and I thought I'd share some of what I learned. I've been using LV 8.20 and NOT upgraded to LV 8.2.1 yet, so hopefully Tomi has helped AQ figure out most of the issues that have come up for me - in fact I don't intend to write about the bugs in LVOOP here at all. (I do plan on upgrading to 8.2.1 right away to see what happens now that I've reached my milestone.) Here are five things that you should consider when starting a LVOOP project (not necessarily in order of importance). 1) Source Code Control Don't even THINK about starting a LVOOP project without it. Unlike in LabVIEW where it is possible (albeit risky) to plug along and not think about SCC too much, it is ESSENTIAL for LVOOP because it is possible for classes to get corrupted and without SCC, you're screwed because you can't do anything to the class file directly. Hopefully 8.2.1 fixes many of the issues that cause corruptions, but at the core, I firmly stand by the statement that if you don't have an SCC process in place, don't use LVOOP. 2) Project Environment I'm not a huge fan of the LV Project environment but you need to get familiar with it if you start working with LVOOP. The biggest challenge right now with the project environment is that it becomes very difficult to organize and find VIs in the hierarchy window (there isn't any support for sorting VIs in the project by name, etc). To get around this, it is best to create a VI Tree for each LVOOP class so that you can easily organize the members in a way that makes sense to you. 3) Context sensitivity One thing to keep in mind, class VIs are loaded into memory differently depending on the context in which you load them. For example, if you start from just LV being open and launch a class member VI, the entire class will be loaded into memory. If you then open a .lvproj file containing the class, you will find the class is locked because it is open in 2 contexts. I recommend creating a VI Tree that contains all of your class VI Trees so that you can open everything in your project in one context outside of the .lvproj in case your .lvproj gets corrupted. 4) Don't use dynamic dispatching on every VI Dynamic dispatching is great, but at the price (for 8.20 at least) of not being able to find your VIs using the 'Find all instances'. So, instead of making every VI in your class dynamically dispatched, use it judiciously in places where you truly want to have over-ridable functions. Where you don't intend to over-ride the function, make the class connection 'Required'. You can always change the connection to 'Dynamic Dispatching' if you decide to over-ride the function later. 5) Be prepared to iterate The one thing I found I had to iterate on the most was abstracting class data from child classes and putting the code into the parent class. Sometimes, even with careful design, you'll find patterns emerging as you develop. If you keep in mind that one good goal is to minimize the amount of code you create, you'll find that you need to move 'generic' functions into parent classes. Remember that a child function that over-rides the parent can call the parent function - so utilize that behavior to reduce duplication of code and then extend that functionality in the child class - or, if a very special implementation is required, skip calling the parent method - whatever option keeps the code tighter and easier to understand. Finally Understand OOP concepts Don't dive in and assume you'll figure it out. Get some OOP books and check out the shipping examples and blogs like Tomi's Expressionflow. Try to create a scale model of your project before implementing details. Quote Link to comment
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.