Daklu

QUOTE (Aristos Queue @ Feb 10 2009, 06:26 PM) I honestly don't think 'significantly off track' is a fair assessment. You addressed, and fixed, a serious problem that affected a large number of people. (Me included!) Sounds like the resources were applied appropriately and effectively. Now that the big beastie is dead the little beasties can be discussed. QUOTE Now, your questions seem to imply that you could have multiple unrelated applications -- the test lab microwave, the cafeteria microwave, etc -- all loading into the same run time environment. Actually I had not considered each of the three classes built into different applications running on the same computer. I assumed Labview would create separate application instances for each application and keep it all straight. QUOTE What was their failure here? Very close. It was more along the lines of, "Let's use HouseholdApplicances as an umbrella namespace for all our tools. Within that we'll have several subnamespaces, such as Microwave, Blender, Toaster, etc. Within each of those subnamespaces we can implement individual libraries or create more subnamespace levels as needed." (Think .NET namespace hierarchy.) Using libraries of libraries (of libraries) to create hierarchical namespaces means that when any single 'leaf' library is loaded the entire hierarchy is loaded. Not the behavior they were hoping for. QUOTE ...libraries, by design, package stuff together... ...your suggestion of a "meta" namespace -- one where a library says, "I'm part of the NI namespace", and multiple libraries might claim that, is interesting. It severs the concept of the namespace from the concept of access scope. Exactly! Libraries and the way the work is a good thing. The bad thing is not being able to arbitrarily set a library's namespace independently of the library's file name. In my mind libraries and namespaces serve two completely different purposes. Libraries exist to package related code; namespaces exist to resolve name collisions. Namespaces should be, in my opinion, much more mutable than file names. (i.e. I should be able to change them without incurring the negative consequences of changing vi or library file names.) QUOTE Currently, if something is inside the namespace then it has the right to access private VIs in that scope. That may be correct from an internal architectural viewpoint, but from my end-user perspective it's false. It should say 'if something is inside the library it has the right to access private VIs in the scope.' From the end-user perspective Labview doesn't even implement namespaces. It implements libraries. Namespace and library are not interchangable terms. QUOTE But such a meta scope, which any library might join arbitrarily, obviously couldn't extend the right to access private functions to just any library that said, "Oh me too!" As you mentioned above, namespace scope is completely separate from access scope. I view namespaces as a kind of virtual organizational hierarchy that is independent of the implementation architecture. Maybe I have an Animal base class from which I derive Pteridactyl.lvclass, Golden Retriever.lvclass, and Cutthroat Trout.lvclass. In my namespace I should be able to put Pteridactyl in <Extinct.Prehistoric.Cretaceous>, Golden Retriever in <Household.Occupents.Pets>, and Cutthroat Trout in <Dinner.BBQ.Yummy> if that's what makes sense in my environment. QUOTE But as a way of providing a common namespace that everything produced by a given set of developers into a unique namespace, it might be useful. It doesn't invalidate the library as namespace -- as I said above, that is a very natural container, and the namespacing there is valuable. To clarify, I have no objection to using the library filename as part of the namespace, such as using it as the last element in the namespace tree. (<Extinct.Prehistoric.Cretaceous.Pteridactyl>) I think that makes perfect sense. I object to the requirement to wrap libraries in other libraries to build a fully qualified namespace. QUOTE When the components are independently developed by unrelated groups of developers, the dynamically loaded components should be placed in a library to namespace the elements... your Austin development team would have their pieces in a library named "Austin.lvlib", and your Shanghai team would have their pieces in "Shanghai.lvlib", so even if they both wrote a "DAQStuff.lvclass", those are two different qualified names when loaded into the framework. This completely contrived scenario, I hope, illustrates the problem of tying the fully qualified namespace to the source code architecture. Granted these scenarios are not among the most common issue encountered by Labview developers, but I can't believe the problems they illustrate are so rare as to be negligible. Suppose I'm using two reuse libraries developed by the Austin development team: Ping and Pong. On my next project I decide to use Pong again, but I also need a few other reuse libraries they developed, Ding and Dong. For parallel project I want to use Ping, Ding, and add a couple classes they created: Sing and Song. Since we want to be sure we don't encounter name collisions between their code and our code now and in the future, we decide to namespace their code. (They don't want to change the name of their reuse code because it will break their applications that use it.) I see a few options, none of which I particularly like: -- I can lump all their reuse code in a single library, Austin.lvlib. Lots of unnecessary code gets distributed with each application. -- I can create copies of the source distribution for each reuse library a given project uses, and include only those copies in a library specifically built for that application. (i.e. Project1_Austin.lvlib) This defeats the whole point of code reuse. -- Rename each of their libraries to a (hopefully) unique name, such as Austin_Ping.lvlib, Austin_Pong.lvlib, etc. Preprocessing their code, I think, is a bad idea. If we ever use reuse code (Sing.lvclass) they created with a non-renamed library as a dependency (Ping.lvlib) we'll end up with duplicate code in Austin_Ping.lvlib and Ping.lvlib unless we manually edit Sing.lvclass to redirect the links to Austin_Ping.lvlib. This problem could easily compound over time until eventually we have two complete copies of their source distribution loose in the company--one using their native names and one with the Austin_ prefix. (There were a few more comments I wanted to make, but I'm literally falling asleep at the keyboard. I hope this is reasonably coherent.)

This thread spawned as a result of AQ's request for users to explain why they use name mangling in this thread. I've taken the liberty to include a brief summary of the relevant discussion thus far: ------ Start Summary ------ QUOTE (Daklu) QUOTE (AQ) Don't use name mangling. It's not needed. QUOTE (Daklu) Don't name mangle!? The last time I skipped name mangling the economy collapsed, I lost my job, my wife left me, and worst of all my dog died! All sorts of scarey beasties will jump out of my closet if I don't name mangle. Surely you can't be serious!? QUOTE (AQ) Yes I am serious. And don't call me Shirley. QUOTE (Daklu) I don't trust Labview. What about the beastie that prevents me from having source code and distributed code with the identical library names loaded at the same time. Oi, the nightmares I'll have! QUOTE (AQ) That beastie is dead. Labview killed it by loading libraries with identical names in different application instances. If you still think you need to name mangle, tell me what other beasties are frightening you. We think we've killed them all but it's possible there are still some that exist. ------ End Summary ------ The way Labview namespacing is tied to the library name seems like an odd decision since it creates potential implementation obstacles that apparently make name mangling the safer route to take, even if it isn't a completely satisfying solution. Maybe these aren't real issues at all and only exist in my mind... First is the potential for name collisions in reuse code. I might have a Microwave class designed to capture debug output from the oven while the cafeteria has a Microwave class for automated cooking and the RF Lab has a Microwave class for testing wireless communications. My application needs to test the microwave oven while reusing code from the automated cooking process and pelting the oven with high intensity radiation. What is the preferred way to use all three classes in my project? Should I copy the code for each class and give them each unique names? Should I wrap each class in its own library and give the library a unique name? This seems like a hack since I'm not using the library to bundle related functionality (it's already bundled in the class) but only for the purpose of establishing a namespace. Using the library wrapper method, what namespace do the class' member vis have? LibraryName.ClassName.VIName? Or just LibraryName.VIName? Second is the inability to create namespaces in a hierarchy that is logical for the organization. I want to be able to create a namespace that makes sense in my working environment. (<MegaBucksInc.ConsumerProductsDivision.HouseholdApplicances.MicrowaveOvens.Test.Microwave.lvclass>) The other microwave classes could be namespaced at <MegaBucks.Services.Cafeteria.Microwave.lvclass> and <MegaBucks.Communications.Wireless.Microwave.lvclass>. We had developers attempt to create a hierarchical namespace by nesting LVLibs but that proved to be unworkable. Is there a reason namespaces aren't implemented as a library property that is independent of the file name, perhaps settable by right-clicking on the library in the project window? QUOTE (Aristos Queue) With exactly identical file names, you can have both your source and distribution in memory at the same time. You load your source in one project and your distrib in another project. They are thus in isolated application instances. Couple questions rooted in my incomplete understanding of application instances: What happens when you load a library outside a project context, such as by opening a .lvlib file from the OS file system? Is there a default application instance that is used? After doing that, what happens if I then try to load another library with the same name outside a project context? Is another 'default' application instance spawned with a different name? How does Labview deal with this situation: An application is built with a static link to a "Honda" class to provide automobile functionality. Later on another "Honda" class is dynamically linked (since it cannot be statically linked) to provide lawnmower functionality. Does Labview automatically coerce the Honda lawnmower class into a different namespace so it can share the same application instance? Does Labview open it in a separate application instance and automatically provide communication between the two? Does the behavior change when moving from the dev environment to the run-time environment?

QUOTE (Ton) 'Mangle' is close, but it still requires prior knowledge of the namespace. I was hoping for a more general solution given an unknown OpenG style namespace. I suppose the best solution would to use a vi reference and pull the path from that. If I decide to migrate away from OG namespaces completely I might just skip the whole thing and hardcode the namespace for now. QUOTE (Ton) The next release of OpenG builder will optionally only mangle the name of the library not the files inside the libraries (like AQ proposed) You can already do that. Turn off namespaces on the General tab and on the Destinations tab set a custom namespace for the .lvclass or .lvlib. QUOTE (Aristos Queue) This should probably move to a new thread, rather than hijack Daklu's original question about how to deal with this, but a detailed list of why, between the project application instance isolation and the library namespacing, prefixing for distribution is still necessary. Better a productive, informative, slightly off-topic discussion than no discussion at all. Besides, that discussion is over... your topic is more interesting. QUOTE (Aristos Queue) If you're still needing it, then clearly there is something that the R&D team does not understand about LabVIEW and how our users are using it... One word: "Incorrectly." The way Labview namespacing is tied to the library name seems like an odd decision since it creates potential implementation obstacles that apparently make name mangling the safer route to take, even if it isn't a completely satisfying solution. Maybe these aren't real issues at all and only exist in my mind... First is the potential for name collisions. I might have a Microwave class designed to capture debug output from the oven while the cafeteria has a Microwave class for automated cooking and the RF Lab has a Microwave class for testing wireless communications. My application needs to test the microwave oven while reusing code from the automated cooking process and pelting the oven with high intensity radiation. What is the preferred way to use all three classes in my project? Should I copy the code for each class and give them each unique names? Should I wrap each class in its own library and give the library a unique name? This seems like a hack since I'm not using the library to bundle related functionality (it's already bundled in the class) but only for the purpose of establishing a namespace. Using the library wrapper method, what namespace do the class' member vis have? LibraryName.ClassName.VIName? Or just LibraryName.VIName? Second is the inability to create namespaces in a hierarchy that is logical for the organization. I want to be able to create a namespace that makes sense in my working environment. (<MegaBucksInc.ConsumerProductsDivision.HouseholdApplicances.MicrowaveOvens.Test.Microwave.lvclass>) The other microwave classes could be namespaced at <MegaBucks.Services.Cafeteria.Microwave.lvclass> and <MegaBucks.Communications.Wireless.Microwave.lvclass>. We had developers attempt to create a hierarchical namespace by nesting LVLibs but that proved to be unworkable. Is there a reason namespaces aren't implemented as a library property that is independent of the file name, perhaps settable by right-clicking on the library in the project window? QUOTE (Aristos Queue) You load your source in one project and your distrib in another project. Couple questions rooted in my incomplete understanding of application instances: What happens when you load a library outside a project context, such as by opening a .lvlib file from the OS file system? Is there a default application instance that is used? After doing that, what happens if I then try to load another library with the same name outside a project context? Is another 'default' application instance spawned with a different name? How does Labview deal with this situation: An application is built with a static link to a "Honda" class to provide automobile functionality. Later on another "Honda" class is dynamically linked (since it cannot be statically linked) to provide lawnmower functionality. Does Labview automatically coerce the Honda lawnmower class into a different namespace so it can share the same application instance? Does Labview open it in a separate application instance and automatically provide communication between the two? Does the behavior change when moving from the dev environment to the run-time environment?

[iE mysteriously posted the message before it was finished. Stay tuned...]

QUOTE (Aristos Queue @ Feb 9 2009, 06:17 PM) Actually I do put all my code in LVLibs or Classes. However, my project currently includes a dozen different classes and lvlibs I have built and distributed to myself over the past two years as reuse code packages using OpenG namespacing. Rebuilding them without the namespaces means I have to go through all the class hierarchies and replace the OG namespaced vis with non-OG namespaced vis. Been there, done that, no hurry to experience it again. (What I wouldn't have given for a 'Select Replacement VI...' dialog box hotkey combo.) In any event, the class I was referring to in the orig post is a distributed reuse class, meaning it is (IMUO) essentially required to namespace the .lvclass by changing the filename. Why? Different class names for source and distributed code allows me to have both loaded in memory at the same time, which makes developing, debugging, and fixing my reuse code much easier. Even if I removed the namespacing from member vis I'm still facing the original issue. I'm not quite to the point where I trust Labview enough to remove OG namespaces from my member vis. Using them works reasonably well and I'm not anxious to run into an unforeseen brick wall somewhere down the road by removing them. Some call it prudence, some call it wisdom... I call it fear of the unknown. (File system restrictions on duplicate file names is one potential obstacle, though not one that affects me directly as I distribute each class/lvlib to its own directory.) I'm almost there... just not quite.

So I was planning on working AQ's Factory Pattern into my project when I ran into a snag. Since OGB (OpenG Builder) creates namespaces by changing filenames, I can't set the path to the desired class in the factory vi without prior knowledge of the namespace to be used. Does anyone have a good general solution to this problem? There are a few options I can think of in order of increasing complexity: Hardcode: Since I do happen to know the namespace to be used, I can simply include it as part of the filename in the source code. (i.e. Generic Plugin\Generic Plugin__namespace.lvclass) Pros: This is the fastest solution in the short term and easy to implement. Cons: Writing code that will break based on a build setting seems like a bad idea. This method could become a maintenance headache, especially for the developer who inherits my code. Implement Path Wildcards: Build a library that allows file system wildcards in path constant. The class source code can simply include a wildcard in the appropriate location. (i.e. Generic Plugin\Generic Plugin*.lvclass) Pros: Fairly robust without being too difficult to implement. Cons: Potential for lots of special case exceptions. (What if there are no matches? What if there are multiple matches?) Use a Translation File: Have the build process create an ini file that includes key-value pairs correlating the original name with the post-build name that is distributed as part of the build. When I need a vi's post-build name I'd simply look it up in the ini file. Pros: At first glance this method seems to be universally robust. The namespacing can be changed arbitrarily without breaking the class' built code. This could possibly be used by programs that consume the built class, meaning namespace changes don't break dependent applications. Cons: I'd have to write a OGB script to perform the translation during the build, which I'm not sure is possible without altering OGB source code. I'd probably also write a small library that looks up and performs the translation transparently. Encapsulation leads me to want to include the translation library as part of the class source code, but that ties class functionality to a file created during the build process. I'm leaning towards the wildcards as it seems to offer a decent balance of dev time, robustness, and flexibility. Has anyone ever dealt with this issue before? How did you solve it?

QUOTE (Aristos Queue @ Feb 3 2009, 09:48 AM) I'm really curious, what feature would break if the original bug were fixed, and can we vote on the relative value of it?

[Edit: I see Omar chipped in and described the same issues I have with hitting the run button on class vis... only he did a much better job explaining it! There's two hours I'll never get back... ) QUOTE (Omar Mussa @ Feb 2 2009, 04:39 PM) I actually wanted to build my application in a way that allowed me to simulate hardware, but when I designed it (before I had any real experience with LVOOP) I didn't really know how to do so. Thanks for the tip. I'll admit I'm not convinced the overhead required to maintain three classes as opposed to one class would have been worth it in this particular case*, but I'll certainly keep that in mind for the future. (*And I certainly wouldn't get approval to go back and refactor it now.) QUOTE (Aristos Queue @ Feb 2 2009, 05:16 PM) Those auto tests have no business, IMHO, running the private VIs... I fully agree with you. (In principle at least... I'll reserve judgement for the practical aspects of it.) It would probably help to differentiate between a developer testing his own checked-out code and turning over "finished" checked-in code to be tested by a third party, such as an automated nightly build. My comments are referring more to self-testing dev code, although it encroaches on the latter somewhat since I don't have software test house. QUOTE (Aristos Queue @ Feb 2 2009, 05:16 PM) You can always hit the run button on any VI for short, quick checks of functionality. I do that when I can. There are a couple issues I've encountered that sometimes make that impractical: One of the main data types I use in my project is a virtual base class. (I derived child classes from the virtual base class to implement vendor specific code for the family of devices I'm testing.) Many of my private sub vis have the virtual base class as an input. Running the sub vi directly instantiates the base class, which of course throws an error when a virtual method is called. Even if I have one of the child classes, some sub vis need the input classes to be in a certain state to execute the intended code. The class default values aren't necessarily the correct ones for that sub vi. Many sub vis need to have several test cases run against them to get good code coverage. It's a pain for me to try to remember all the combinations of inputs that need to be tested and what their outputs should be. I'd much rather just click a button to test them. Those issues have led me to building many test vis for private vis that include setup, input/output comparisons, and teardown. (I'm looking forward to using the test framework!) -------------------------------------- FWIW, in my second post bullet #2, more than any of the others, is what drives me to test private sub vis. If the public vi doesn't have a testable output, how do you verify it? Case in point: My project uses NI Motion to control a robot. Several of my public vis are broad 'action' vis, such as to execute a specific test. Buried several layers down in the private sub vis are a set of functions that take data from the public vi's front panel, the motion controller, and the device being tested to create an array of positions for the robot to move to. The public vi doesn't have any outputs other than a few pass-through inputs and an error out indicator. From the standpoint of only testing public vis, I don't see a realistic way of making sure that set of vis is functioning correctly and creating the coordinates I expect. As it turns out, there was a bug that caused the coordinates to be off by a couple mm, but under most of my test conditions it wasn't noticable while watching the robot. I found it when I was doing some tweaking and happened to increase the spacing between each robot coordinate. Then the error became large enough for me to notice.

QUOTE (jdunham @ Feb 2 2009, 09:41 AM) I'll tell you why *I* write test cases for private vis, but I'll leave it to those smarter than me to debate the 'correctness' of doing it. The short answer is sometimes I make changes to private vis that inadvertently 'breaks' (as in it still executes but doesn't operate correctly) my application and it's easy to run a test case on a private vi to make sure it's behaving the way I expect it to. The long answer is multifacited: Many of my classes are hardware dependent and I don't always have the hardware available to test the class as a whole. Testing sub vis gives me some confidence things will work when I connect to the hardware. Even if I do have the hardware available, you can't always test the results without adding other instruments to the system. (Managers tend to not like spending money on 'stuff to test the stuff I test our stuff with.') For example, my Weather Toolbox has a Rain class that includes a Rain.Stop public vi. I can't automate testing that vi without adding expensive instrumentation, but I can test the sub vis I use to make sure they work as expected. I use test cases to make sure the private vis I use in Rain.Stop are sending the correct messages to the vendor's Rain API. My private vis sometimes go several levels deep. I find testing private sub vis helps me locate bugs quickly, especially when I've had to change several sub vis at one time. I don't know any better... I'm always willing to learn better ways of doing things if they address these issues. QUOTE (Aristos Queue @ Feb 2 2009, 02:54 PM) Given all this, if you test your private VIs, you're going to become aware of defects that don't matter, and you'll waste development time fixing them. Only if you first waste development time broadly implementing tests that don't matter. At some point you have to trust the developer to know what needs to be tested and what doesn't in a given vi. QUOTE (Jim Kring @ Feb 2 2009, 10:32 AM) Another strategy (aside from making the test VIs members of the class under test) is to put anything that needs to be tested outside of the class under test. For example, if they are generic support functions, you could put them into another lvlib and make them public. That doesn't work so well in my case--the sub vis I want to test tend to be very specific to the class or library I'm creating. They aren't meaningful outside of the context of the class.

JKI's newly announced VI Tester prompted me to finally post a question that's been on my mind for several months... I often write test vis for a class' private subvis which obviously requires me to put the test vis in the class. I don't really like distributing test code with the class. Manually removing the test vis from the class for every build is a drag. (...and drop too!) I use OpenG Builder and OpenG Package Builder for my code; I believe it is possible to write a vi that will remove test vis from a class that I could use as a pre-build script, but I haven't had the time to really dig into it. What are some strategies others use for testing private class vis, with or without the OpenG packages?

QUOTE (Aristos Queue @ Jan 1 2009, 09:20 PM) Since they are all Value Changed events, I'll make the bold assumption you're referring to the X and Y Value Changed event. :laugh: I'm wondering why you suggested that particular refactoring. How would the compiler treat the current code differently if we pull the x and y terminals out of the event structure? I assume it would do as coded and assign the front panel value to a memory location on every loop? Any idea how that overhead compares to the overhead of monitoring an event? I only ask because I tend to use these manual "optimizations" as well since I don't know smart the compiler is and from what I've read it's "better" to put something like changing the x and y value in an event rather essentially polling them on every loop. (Obviously there will be very little performance difference in this particular example. It's more a question of style and principles.)

Here's a quick demo I put together that does what I think you're trying to accomplish... Download File:post-7603-1229736409.zip

I could be wrong, but I don't think there's a way to directly recast a parent object into a child object. I would have tried the same thing you did--create a child object with a copy of the parent data. AFAIK that should work as long as you have the correct methods exposed. What error did the compiler give you when you tried this? This link [http://decibel.ni.com/content/docs/DOC-2875] doesn't directly answer your question, but it sounds like you are implementing a Factory Pattern.

QUOTE (san26141 @ Nov 18 2008, 02:49 PM) No, what you are showing is not inheritance. You are including Class_X and Class_B as a private data members, which is called aggregation. QUOTE (san26141 @ Nov 18 2008, 02:49 PM) 1) When I have to "INIT" Class_B from within Class_A:Init how does each instance of Class_B get its own unique parameters? You can't in your example (assuming the parameters are not already contained in the class data.) QUOTE (san26141 @ Nov 18 2008, 02:49 PM) 2) How does Class_B:Init know to initialize Class_B.lvclass different from Class_B.lvclass 2 different from Class_B.lvclass 3? - For example each instance of Class_B is initialized with a different COM port. There are two ways: If you want to assign parameters to the Class_B object in Init.vi you need to create an input to the vi and wire unique inputs to each instance of it. Store the parameters as private class data, and create accessor method VIs to manipulate the internal parameters. For example, you could have a numeric control named com_port to store the com port number. Then you would create a Set COM Port vi and a Get COM Port vi to write and read the private data. You would use Set COM Port at some point prior to calling Init. Then, within Init.vi, you can unbundle the private data and use the com port number associated with that particular object rather than relying on Init.vi input parameters. QUOTE (san26141 @ Nov 18 2008, 02:49 PM) 3) Can the input lines (blue arrows below) be used to tell the method which parameters to initialize the calling instance? The "input lines" you are referring to are in fact object wires, and carry all the information pertaining to the object on the wire, including the values of all of that object's private data. So the quick answer is yes, the object wires can indirectly tell Init.vi which parameters to use (although it's probably in a different way than you intended.) QUOTE (jdunham) Usually a LabVOOP Initialize method does not take a copy of the class in, and therefore is an initializer because the new wire out is the first time that object's wire and the data its holding comes into existence. If you want your initialize method to be inheritable it needs to have a class input, otherwise LV doesn't know which class initialize method to call. (FWIW my initialize methods are reserved for initializing hardware. I use create new methods when I was to control how new objects are formed.)

...because the best way is clearly to use VIPM. However, since I don't have that option atm I'm wondering what the second best process is. I'm attempting this using OGPB (OpenG Package Builder), but I'm interested in any solutions people have come up whether or not they use OGPB. What I've done in the past is build my code and put it in the installation directory, then use the Edit Palettes... function from within Labview to create the mnu file. That's really cumbersome to maintain so I'm trying to come up with a solution that allows developers a way to design the palette at design time. My main functionality uses VI Refnums and the newly released Palette VIs to create a mnu file when I run OGB (OpenG Builder) via a post-build vi call. This part works great and correctly handles the build process name mangling and file relocations. Unfortunately the mnu file in my build directory doesn't link to the correct files when I move them to the install directory. (Duh.) When I tried using a similar post-install vi call in OGPB it didn't work, as the post-install vi seems to be executed from a temporary directory and it couldn't find the sub vis needed to build the mnu file. I looked at the OpenG dynamic palette api for a while but couldn't quite make sense of it and didn't find any examples of it being used.

QUOTE My experience is that management in most places is like that. VIPM isn't required to do the job, it just makes certain aspects of it easier; therefore it is an unnecessary expense. On top of that Labview isn't that widely used in my group... QUOTE ( @ Oct 28 2008, 11:34 PM) 10 licenses for the price of one. 10 for 1? That I might be able to sell, but I didn't see the offer on the VIPM website.

QUOTE (crelf @ Oct 28 2008, 09:30 PM) As much as I'd like to use it, cost is the barrier stopping me from using it. Yeah, it would pay for itself by saving me time, but my incremental cost is somewhat hidden while cutting a PO for n VIPM licenses is sure to raise a few eyebrows.

QUOTE (jlokanis @ Oct 28 2008, 06:10 PM) I think I'm following you... it sounds like you are building LLBs to take a snapshot of your reuse code and by using the snapshot in your application code you avoid breaking the app with future changes to your reuse code. You avoid conflicts by giving each snapshot a unique namespace via OGB. If that's correct, couldn't the same thing be done by copying your reuse code to a different location and wrap it in a uniquely named LVLIB, since, as near as I can tell, that's essentially what you're doing with the LLB. (With the obvious difference that you're wrapping it in an LLB instead of an LVLIB.) What am I missing?

QUOTE (Aristos Queue @ Oct 28 2008, 04:25 PM) OGB = OpenG Builder. (I edited the OP for clarity--I used only the acronym the first time around.) OGB creates namespaces by appending suffixes to filenames when the code is built. QUOTE (Aristos Queue @ Oct 28 2008, 04:25 PM) A library is a namespace. There are many types of libraries. Among these are the .lvlib file and the .lvclass file. So, yes, there is already a namespace for the VIs in the class. Now, if you want to namespace the class itself, put the class into a .lvlib. So if I understand the ramifications correctly all of the following are true...? 1. Assume I have a Boat class and a Car class that are independent of each other. Both classes have a Start method. I am safe using these classes within a single project since the two Start vis belong to different namespaces. 2. Assume I have one Honda class that inherits from a Car class and another Honda class that inherits from a Lawnmower class. Since the class itself isn't namespaced, I'll run into conflicts if I try to use both of these classes in a single project, regardless of whether or not they have any common vi names. (If this is true, that implies namespaces don't propagate down through a class hierarchy. i.e. Instead of Car.Honda(.Start.vi) the namespace is just Honda(.Start.vi.)) 3. VI filenames are independent of the namespace that contains them, therefore VIs with different namespaces may have the same filename and I may run into occasional conflicts if I'm not careful to separate my namespaces into different directories in both source and distributed code. Are there other namespaces outside of .lvlib, .lvclass, and (presumably) .llb files?

I've been using OpenG Builder for several months for distributing my reuse code to myself. All along I have been using OGB's namespace feature. A couple weeks back I was demonstrating OGB to some coworkers and the one of them raised the question, "Why not just use the .lvlib namespace feature?" Aside from the extra step of wrapping all my reuse projects in a lvlib to make use of the namespace, I didn't have a good answer. Anyone want to take a stab at comparing/contrasting the two namespace implementations? Tangential question: Do LVOOP classes automatically generate their own namespace making OGB and lvlib namespaces unnecessary?

QUOTE (Aristos Queue @ Oct 23 2008, 10:07 PM) Classic post. And I'll bet it took you all 1 hr 6 minutes to write it. (It was time well spent.) QUOTE I was told we couldn't just make up words... Why not? As you pointed out, you can't hardly be n'americun without having made one up. Besides, once you make it up you can trademark it and make millions. QUOTE (Aristos Queue @ Oct 22 2008, 04:11 PM) The word is "sourcenders". For any given project item under Dependencies, sourcenders are those project items under Source that, as a result of some chain of dependencies, are the reasons that the original project item is included under Dependencies. Or, to put it another way, in any given chain of dependencies, sourcenders are the last items that are under Source and the rest of the dependency chain past that point is listed under Dependencies. I'm glad you're looking into this. On more than one occasion I have accidentally pulled in an incorrect dependency and had to spend considerable time finding the guilty vi. (For instance, accidentally using source reuse code instead of distributed reuse code.) I think, however, that you are aiming at only half the target. In the example given asking for the sourcenders of E returns B, C, and F. The problem is that I can't find E anywhere in B or F so I end up having to dig deeper to find and break the dependency. What the user needs to know is the location of the bridges between source and dependencies. In order for a bridge to be a bridge, it must have anchors at both ends. (Otherwise it is a ramp...) In use, I could pop up on E and select "Find Bridges" which would return the anchors for each bridge. Perhaps something like... F.vi <--> D.vi B.vi <--> D.vi C.vi <--> E.vi Ideally "Find Bridges" would work on more than just a single vi. I'd love to be able to pop up on a class or lvlib and Find Bridges. Using "Find Callers" on them doesn't work so well...

QUOTE (jcarmody @ Oct 15 2008, 02:59 AM) Who knows better what a spec should contain (i.e. how to write it) than the person who has to use it to implement tests? Ideally, specifications (engineering requirements) flow naturally from product definition (customer requirements.) My experience is that poorly-defined and changing specs are often due to an inadquate product definition. Unfortunately marketing/product planning has no idea how to properly define customer requirements. (I've seen the requirement "our product needs to perform as well as competitor-x" too many times to count.) In my opinion, you're not going to get a good specification unless design and test are involved at the very beginning of the project, when marketing/product planning is first defining the product. In other words, a document template probably isn't going to help you much. It sounds like there are deeper organizational problems there. (I spent 5 years at my last job trying, without success, to get into the product definition phase so I could help them create a meaningful product definition.) In fact, spending your political capital on applying a band-aid to a broken arm could end up hurting your work reputation.

QUOTE Nope, this was with 8.5, although I have since upgraded to 8.6. QUOTE If you have a project in 8.6 that doesn't show the missing file, I'd be interested in looking into that as a bug. If I see the error again I'll store and tag it in our scc.

QUOTE I'm a cat owner by marriage, not by choice. Besides, I was rather hoping the cat would choke on it... QUOTE The project window should show you the missing VI, with a bright yellow symbol next to it to make it easy to spot. I've had this error occur a couple times in the past and I have never had the missing vi show up in the project window, either in the class it is missing from (else it wouldn't be missing) or in the dependencies (as there are no other vis that are dependent on it.) QUOTE Believe it or not, at the point where that string gets generated, I no longer have access to the object itself to get that file name. When I calm down and think rationally I'm sure, as you indicated, there are valid reasons specific perceived flaws are the way they are. Improving software based on 20 years of legacy code is no mean feat. I really don't fault anyone at NI for Labview's shortcomings. Like I said, I was extremely frustrated and needed a way to vent so I could continue working. (Although I am surprised it is something you have looked at changing... is there anything you don't have your fingers in?) Now I have to think of a different way to dispose of a cat...

Grrrr... If Jim Trouchard were here right now I'd poke his eyes out and feed them to my cat. WHY DO I HAVE TO SAVE MY PROJECT TO SCC EVERY FRIGGIN' 5 MINUTES TO PROTECT MYSELF AGAINST LABVIEW CRASHES!? Some days I spend more time fixing problems from crashes than working on code. It certainly doesn't help my efforts to promote Labview when I have to tell my manager I spent the entire day trying to recover and rebuild code I had already finished... again. The latest crash left me with the error, "This class is missing one or more member vis." Yeah? Thanks for noticing, but how about if you tell me something useful, like WHAT THE NAME OF THE MISSING VI IS! Telling me a class of 150+ vis is missing one vi is enough to make me... want to feed JT's eyes to my cat. Words simply cannot express how &%*()# mad I am right now. But since I can't start yelling and throwing things this is about as good as I can do right now. (And it's woefully inadequate.)