NATE

I found the App::Linker.Read Info From File method. I don't understand everything that it returns, but I think all I need are the file paths so it seems to be working great.

How do I programmatically determine ALL dependencies of a VI? It's easy to call the Find Dependencies method, but this only returns paths to VIs and controls. I want to find all types of dependencies so that I can copy all dependencies to a new location. Essentially I want a miniature version of OpenG Builder. It's easy to get the library path of each returned VI, but what about other types of files like .rtms, .dlls, etc... Even for libraries, the rules are different based on library type. If the library is a .lvlib, then the lvlib is the only additional dependency. If the library is a .lvclass, then all of the members of that library are also dependencies because the class is not usable unless all member VIs are found. I'm afraid there may be so many exceptions and things I haven't considered that I don't think I can reliably create this functionality from scratch and have it work with all possibilities of dependencies. I'm not using OpenG Builder or Application Builder to do this because the list of VIs I want to run this on can't be known until run time. I'm not sure if OGB or AB can be automated in this way. Any help or guidance on this would be appreciated. I'm using LV2009 SP1 and Win XP. Thanks, Nate

I'm sorry, it's the above image of the while loop with the Context.Ref Count.Dec method in it. The invoke node is throwing a LVContext.cpp error.

I found this snippet of code in DEAB Open LV80 Project App Reference.vi because it is currently throwing an unhandled exception for me, I'm hoping you can help me out. I'm attempting to use OpenG Builder 3.0 with LabVIEW 2009 SP1 on WinXP. It works fine if I perform the build through the Builder GUI, but when I try to automate the build using Build Application from Build File__ogb.vi, this exception pops up. The subVI calling this VI is a member of an .lvlib containing all of the code to perform the total automated build. This .lvlib was itself auto-created by a Source Distribution build spec. This same automated build process worked fine with OpenG Builder 2.0 and LV 8.6.1. We just updated to LV2009 this week. I'm tempted to use VI Scripting to have my build tools auto-comment this snippet of code out to prevent the error. I have to do it this way instead of just modifying OpenG builder because our build tools have to be CM'd so the builds can be performed by our SQA. But that feels like a real hack. The built application otherwise comes out fine, it just pauses my build tool in the middle, which is a booger because there's a lot more my build tool has to do after the EXE has been created. Thanks for your help! Nate

I admit I don't know much about genetic algorithms, but I remember seeing something on the Discovery Channel a couple of years ago about an application that was written to attempt to demonstrate evolution. Basically he created a bunch of blobs on the screen. I think each blob had a maximum life span, but could die earlier due to lack of nutrition and maybe attack from other blobs, can't remember. The blobs could move, always seeking out food particles. I don't think the blobs mated, I think once they acquired enough food they could asexually have offspring. Random permutatations were allowed to be introduced each time an offspring was born. In theory, the permutations that were beneficial increased its likelihood of survival. But what I don't know is if these "random permutations" were controlled or if it literally allowed any bit in that object's memory space to be modified. This seems highly unlikely because then you would end up with a vast majority of the offspring being "uncompilable". But every so often, you might have an evolutionary leap, and the child might be able to move 10x as fast as the parent, or defend itself better, or have a longer lifespan, or whatever. Very interesting idea, but the practicality of it seems nearly impossible. And even if it was possible, VI Scripting isn't terribly speedy, so I'm guessing a LabVIEW implementation of this same type of simulation would run at a fraction of the speed of C or C++, and there's the problem that LabVIEW doesn't really give you the ability to modify any memory address.

Thanks for the post Stephen, I was hoping you'd chime in on it. Everything you said is as I expected, just good to get confirmation. Though I admit I don't understand the significance of loading strict VI references vs. non-strict when it comes to scope checking... I think being able to compile the parent class and child classes independently is a great feature. I haven't had an opportunity to "deliver" an overriding class to a customer, or an application with a plug in architecture using child classes, but I'm delighted to have those as options. Thank you for the extra work I'm sure this must have taken the LV R&D team to make this happen. I've read the Decisions Behind the Design, I've taken the GOOP training at NI Week, and I've done a fair sized project with LabVOOP now that does make heavy use of inheritance and dynamic dispatching, but I still have mixed feelings about data members being private only. Public data is bad, agreed, but having a protected data option would be very convenient, and I almost think it should even default to protected. The reason I say this is the same motivation as the customer requests that binaries be independent for parent and child classes. If I want to create a child class that extends the functionality of the parent class, it's almost guarenteed I'm going to need access to the data in the private class. If the author of the parent class did not forsee all the ways their class might be extended (which is an impossible task) and did not provide public or protected accessor/mutator methods for data in the parent class, AND if the author of the child class does not have access to the source code of the parent class to add accessor/mutators as needed, then the ability to extend functionality becomes very limited. However, Decisions Behind the Design says this decision was not only made based on best-practices OOP theory, but also technical requirements in order to isolate the compilation of the child classes from the parent class. If that's the case, then I think you made the best decision in the long run (we just haven't experienced the benefit of that decision yet since the awareness/use of LabVOOP has not risen to the level where people will realize the power they've been given). I would ask that NI advertise this reasoning more in LabVOOP training and Dev Day presentations. A real world example of when default protected data would have been nice: Sometime between LV 8.2.1 and 8.6 the NI Report Toolkit moved to OO. Unfortunately we had some code that was accessing some data in the Report Toolkit which became private when we upgraded to 8.6. This broke our code of course, but the easiest fix for us would have been to create our own class that inherits from the Report Toolkit class so we could access that data and go about our merry way. Now, I know what you're going to say, that's not the best way to do it because it means we're still directly accessing your data structures (breaking encapsulation), and if NI changes their private data structure it would break our class, breaking our code once more. Your right, but it illustrates that the use case of "deliver a class as a binary without access to the source" can only really be done if the author of the parent class knows exactly how all customers might want to extend the class, OR the author of the parent class creates protected accessor/mutator methods for all data members just to support future unknown child classes. Instead we had to rewrite a good bit of code to avoid using that private data. Again, for the sake of protecting ourselves from future NI code changes, that is the right thing to do, and therefore the decision to make all data private is the safest thing a class producer can do to avoid breaking child classes on future updates. But in cases where the child class author does not have access to the parent class source, its also very inconvenient and limits the customer's ability to extend your classes. Thanks for listening, your contribution to this forum is invaluable, Nate

Is variable scoping (public, private, protected) in LabVOOP only performed at design/compile time, or is it also checked on each access at runtime? I would think checking access permissions on each call to a variable at runtime would be prohibitively slow compared to compile-time-only enforcement of scope rules, but I'm wondering if LabVOOP might be doing this anyway to support the plug-in architecture design pattern using the Get LV Class Default Value node. This node gives you the incredible capability to load a child class into memory while an application is running and begin invoking override methods. If a method in this child class attempts to access a private data member in the parent class, what prevents it? I'm hoping the only thing that prevents it is the fact that the child class should be broken at design time by the LabVIEW compiler, and attempting to load it using the Get LV Class Default Value should gracefully report an error that the child class has errors, but I'd like get a solid answer to this question. Motivation for the question is curiosity and performance relative to C++, but I confess I have not attempted to do any benchmark testing. I'm using LabVIEW 8.6 Pro on Win XP. Thanks, Nate