Yeah, I have to figure out the best architecture for doing that. But getting all the HW dependencies into a single child class sort of breaks my original straightforward model of each test type being a child class. In any case its probably less work for this application to just maintain all the supporting drivers for all the HW. For my most recent app I went back to my old variant-cluster based test executive and left out the LVOOP. Not as sweet, but it does the same thing.
I am extremely worried to even try dynamic launching of LVOOP method vi's. I have had to strip out all VI server and dynamic calling of vi's from my LVOOP applications, because the exe builds kept getting terribly messed up. In 8.2, LVOOP and dynamic vi's (the original type of dynamic vi's) in the build do not get along well, to the point that it was basically impossible to get the build to finish. In certain places I was dynamically calling non-method vi's that were also contained as sub-vi's within class methods. Bad idea! I spent days trying to get the thing to build an exe, and I finally figured out it was because I had some vi's listed in the "dynamnic vi's" section of the build. Once I removed all those my problems mostly went away. But the thought of dealing with those types of problems again, where broken vi's mysteriously appear during exe builds, but the vi's mentioned as broken aren't actually the vi's that are breaking... no thanks. Our in-house development rule is no LVOOP and VI server in the same application!
In the future I think the easiest thing will be to clone the entire project to a new directory and strip out the HW dependencies from the classes. It will be two sets of the app to maintain in separate projects, but its probably the easiest way to release non-HW-dependent versions of the classes into an top-level exe.
Message Edited by billings11 on
04-22-2008 08:20 AM
-Devin
I got 99 problems but 8.6 ain't one.
