Daklu

QUOTE (crelf @ Mar 3 2009, 01:31 PM)

Did you have a probe on an error cluster?

Well not anymore... :laugh: I could have at the time though. Why?

Koo koo kachoo

I had thought Labview automatically saved the object's state when writing to disk and would restore the object to that state when loaded. I can't say I've ever tried it though and seeing you ask the question makes me think I was wrong...

QUOTE (neBulus @ Feb 27 2009, 05:57 AM)

As soon as the proper item is selected a left-click on the diagram should start the drop.

Where or why does the enter key get involved?

Whaddya know... it works!

Two things threw me off here:

1. I'm so used to needing to do some other keyboard action to 'confirm' auto-complete guesses in other applications it never even occurred to me to try clicking on the BD.
   
2. The Quick Drop box looks an awful lot like a regular dialog box, which as a general rule requires some sort of user interaction to dismiss. Hence my normal habit of double clicking on the list box or hitting the enter key. (Although I always thought it was odd there wasn't an 'OK' button there.)
   

Thanks for the tip!

I've been forcing myself to use quick drop recently and am learning to like it... except for one small thing that's been annoying me. I almost always get the correct function highlighted in the top edit box within 2-3 keystrokes, even if the main listbox still has dozens of entries in it. What I'm finding irritating is to select the function in the edit box I need to either find it in the list box and double click on it (a relatively slow process) or hit the 'Enter' key, which requires me to move one of my hands away from their regular coding positions. (Left hand on ASDF, right hand on mouse.)

Is there a way to bind another key to perform the 'Enter' key function? I'd like to use the Tab key to accept the auto-complete guess, but other options such as Ctrl-Space or even Shift-Space would work for me as well.

QUOTE (benjaminhysell @ Feb 26 2009, 01:57 PM)

Is this a common use of the Package methodology? Would I be better off sending out Project Libraries to my developers?

I recently converted to packages exclusively to distribute reuse code--mostly to myself, but occasionally to others as well. Managing versions and keeping all computers updated with the latest releases is much easier with VIPM than with copy-and-paste.

On the JKI forum Jim mentioned including the parent class as part of the project. Personally I prefer to remove it from the project once I set up the inheritance. The parent class is still available in the Dependencies section of Project Explorer, but the separation makes it clear to me that I should not be editing the parent class' source code. As near as I can tell there's no practical difference between the two methods; it's just a matter of personal preference.

QUOTE (Aristos Queue @ Feb 20 2009, 02:43 PM)

if you've never seen the black background before and this is your first explanation of it, you may be thinking, "That's farily obscure... how was I supposed to know what that means?

Actually I was thinking, "I hope this isn't a totally stupid question that everybody except me knows about."

QUOTE

Agreed, although using non-default values on a control that has hidden values seems to violate much of what Labview programming is about. I'm still trying to think of a valid use case for this particular trick.

QUOTE (Aristos Queue @ Feb 20 2009, 11:20 AM)

...so if your private data cluster contains a numeric whose default value is 5, this control may have the numeric with a default value of 6.

Since you can't set class values on the front panel like you can with most controls, how would change the default value of a class control? I tried changing the default values of the class but as expected all the front panel controls were updated to the new default value.

QUOTE (Justin Goeres @ Feb 20 2009, 09:25 AM)

My recollection is that it means the default value of that control is of a class other than the class type of the control. E.g. your control is of type Multimeter.lvclass but the actual default value of the front panel terminal is of something like Keithley.lvclass, which is a child of Multimeter.lvclass.

Odd, especially since that class inherits directly from Labview Object and has no children. I dropped another class cube from my Project onto the FP and it looked normal. Labview crashed when I probed the wire and tried to run the vi. I guess it meant Labview was confused. :laugh: When I restarted Labview all was back to normal...

(In fairness, previously I had been mucking around with the inheritance of many classes in my project.)

What does the dark border in the class cube indicate? It changed when I renamed the class. I've saved and mass compiled the project and the error window is clean.

QUOTE (Aristos Queue @ Feb 16 2009, 07:08 AM)

CAR 146495

Is there a way for users to search known bugs? A couple searches on NI's website didn't turn up anything helpful.

QUOTE (jdunham @ Feb 15 2009, 10:40 PM)

I don't believe this is an intractable problem. http://joelonsoftware.com/articles/fog0000000356.html' rel='nofollow' target="_blank">This article from joelonsoftware is somewhat helpful.

Good article. The recent discussions on the importance of good specification documents also relate to this problem.

QUOTE

I appreciate you taking the time to think about it. Being essentially a single developer learning Labview by trial-and-error means I turn to LAVA as a primary resource when I run into problems. Sometimes I can state the problem clearly and concisely; sometimes the scope is broad enough I end up throwing chum in the water to see what surfaces. In this particular case my bait was no good. Reading my posts might leave others puzzled, but at least taking the time to type out a post describing the problem nearly always helps me understand it better.

QUOTE

The root problem is that the new requirements violate the assumptions used to create the original architecture. The original design assumed each control panel will always use a single type of communication. For example, we always use I2C communication to talk to the TouchMagic control panel. To give the TouchMagic child class the ability to talk to the hardware it contains an I2C Interface Base Class object as private data. Now I'm faced not only with supporting multiple communication methods for each device but the possibility of multiple simultaneous communication methods. (Such as sending data to the control panel via I2C and reading the response through the microwave's debug serial port.) One implementation is to create multiple TouchMagic child classes with each one containing a different combination of communication methods. (I2C only, serial uart only, I2C write-serial read, etc.) Following that path will quickly lead to unmaintainable code. There are other short-term hacks I could (and have) implement to provide the immediate functionality required, but it's a path that will get ugly quickly.

Since communication methods are subject to change and the communication hardware classes don't have a common ancestor class, I started looking at interfaces/delegates. Unfortunately there are not many examples of implementing delegates in Labview and I'm uncertain about what the tradeoffs are in implementing them. ("Chum, meet water.")

[Note - Read the end of the post before you spend any significant time thinking about this.]

QUOTE

My comment was a very poorly worded last minute addition that followed a lengthy line of thought I didn't lay out. Forget I ever mentioned it. (But yes, the semaphore is the solution to that immediate question.)

QUOTE

Been trying for over a year. Not going to happen. As a matter of fact, I just found out my manager is taking the development responsibility for this test system away from me and turning it over to a software test tools team to port the whole thing to c/c++/c#. :headbang: Due to my pointy-hair my questions have become largely academic, but I'll continue researching an answer anyway.

One workaround is to leave the source code unprotected and apply a password when you build the code. OpenG Builder has an option that sets a random password at build time.

When creating class member vis using using Right Click -> New..., the naming convention of the class input and output in the automatically generated member vi is not consistent.

New -> VI from Dynamic Dispatch Template and New -> VI from Static Dispatch Template use the class' localized name as set in the class properties dialog box but automatically removes the .lvclass extention.

New -> VI for Data Member Access appears to use the class' filename.

QUOTE (jdunham @ Feb 13 2009, 01:48 PM)

Geez, I hate to deconstruct a joke too far, but the point is that the software developer was the one who projected all the extra requirements by over-generalizing, while the king just wanted a toaster. It's a cautionary tale, to be sure.

Oh I understood the intended message. I just chose to look at the story from a different perspective.

QUOTE (Phillip Brooks @ Feb 10 2009, 03:41 AM)

I have nothing to contribute to solving your problem, but since you use a toaster/microwave analogy I had to share this link that I Stumbled Upon last night.

That was funny, but I can't help but have sympathy for the software developer. That advisor was in a no-win situation the moment the king found the toaster. Nobody in their right mind would ask the electrical engineer to "just tweak it so I can cook a ham and cheese omlet" after he shows them the prototype. It's plain by looking at the device that it's not suited for that task and would require extensive redesign.

Software developers aren't so fortunate. It's impossible for a person to get an intuitive understanding of the capabilities and limitations of the software prototype by glancing at the finished product, so they ask for unreasonable requests and expect them to be easily implemented. Eight years ago I was writing test software for an R&D engineer. Every time I sent him updated software, the following morning he was at my desk saying, "Your software is really good, but could you just change it so..." Lather, rinse, repeat. I left that job. Even software developers are guilty of it, as evidenced by the suggestions (mine included) on LAVA for ways to implement Labview fixes.

Moral of the story: Recognize that when your king finds his toaster your goose is cooked.

As an aside, I still haven't figured out how to address my problem.

QUOTE (Aristos Queue @ Feb 11 2009, 02:40 PM)

If the namespace is not used anywhere other than load, how do you invoke subVI calls?

Magic?

QUOTE

Yep, bad oversight on my part. I hadn't thought about how to link the block diagram subvi with the runtime instance of the subvi. That's probably why I'm a test engineer instead of a design engineer--breaking things is easier (and far more entertaining) than building them.

My original thought had been for developers to apply namespaces on an 'as needed' basis on their dev computer. That would maximize malleability and avoid the overhead (both in terms of processing time and human management) associated with designing and maintaining a complete namespace structure. In retrospect it's obvious that doesn't work. The deployed application might try to reference a pre-installed shared library that, even though it is the same library, has a old namespace. The app, finding mismatched namespaces, determines the library it needs isn't present and throws an error.

Following that line of thought leads me to believe a fixed, centralized namespace lookup table is required. (Although if the table is generated at runtime it would provide more flexibility.) The question that naturally comes to mind next is: What's the point of implementing namespaces if you can't change them without breaking applications? Have the problems of changing filenames simply been shifted to the realm of namespaces?

I actually thought about this a lot today and think namespaces are still advantageous. Naturally a library has a 1-to-1 relationship with its filename. Is there any reason a library couldn't have a 1-to-many relationship with namespaces? I believe allowing a library to be accessed in source code through multiple namespaces could help provide a migration path for Ping/Pong situations.

For convenience, let's assume the default namespace for libraries is <User>. When we realize Austin's <User.Ping> conflicts with our <User.Ping>, we call them up and decide they will use the <Austin> namespace and we will use the <Seattle> namespace. We each add the namespace to our Ping.lvlib source code and redistribute the built code to our developers. Now their library can be accessed via the <User.Ping> and the <Austin.Ping> namespaces. Similarly our library can be accessed via the <User.Ping> and the <Seattle.Ping> namespace.

In the application we are building that uses both libraries we reference them through their new namespaces, <Seattle.Ping> and <Austin.Ping>. Legacy applications which use only our library continue to reference it through <User.Ping>. Using this scheme we can continue to make updates to our Ping library and all legacy applications will remain functional. Our legacy applications can be updated to reference <Seattle.Ping> instead of <User.Ping> at our convenience.

There is a significant limitation that this technique doesn't fix. An application cannot reference either library via <User.Ping> if both libraries are present on the system, unless one of them drops out of the <User> namespace. That puts some restrictions on having multiple applications using those libraries installed on a single computer.

Still a net positive in my mind, even if not as easy to use as I originally imagined.

QUOTE

An identity hash would do it. It has limited practical value (to say the least) but it is logically possible.

QUOTE

Given prior information about the distribution of the data to be sorted algorithms can sometimes be constructed that operate faster than that. It also depends on the type of sorting being done. I can sort my dirty laundry in O(n). (Whites, darks, and colors.) Oddly, when I'm tired my laundry sorting algorithm improves to O(1). Special cases? Yep, but logically possible.

QUOTE

Yeah, okay... you got me there.

The Ping/Pong scenario is contrived, but the issue it illustrates is real enough to me. This is the real situation I'm in right now.

I work at MegaBucks, a large company spread across several organizational divisions and dispersed geographically. In my group I was the first one to start using Labview. I created several reuse libraries to solve immediate problems and facilitate future code. Over time a few other people in my group started using Labview and used my reuse libraries. A little more time passed and I discovered a group of Labview users in a different division working on similar problems. I have since found a few other islands of Labview in various locations.

When I first created those reuse libraries I gave them names that were descriptive enough for the context in which I anticipated using them. Robot.lvclass, ButtonPusher.lvclass, DataAnalysis.lvlib, etc. Unfortunately these names are too general to be meaningful when the code is shared with the other Labview users. In the best case the purpose of my reuse code is somewhat obscured in their project; worst case is a name collision with one of their reuse libraries, which incurs the developer overhead I mentioned above. Either way sharing reusable code is hindered.

Maybe I should have given my libraries more descriptive and unique names. After all, Robot.lvclass is an extremely general name and a good developer should anticipate a name collision somewhere down the road.

I suppose the name could have described what the robot does rather than what it is. Except I work in a development test environment; equipment is frequently repurposed to accomplish new tasks. My control panel testing robot today can easily become a glue dispensing robot tomorrow.

I could use NI's convention of prefixing the library with an abbreviation and call it MB_Robot.lvclass. Oops, the other groups might use that convention too, so I'll have to extend that convention to include the organizational structure: MB_ConsumerProducts_HouseholdApplicances_MicrowaveOvens_Test_Robot.lvclass. At least that accurately describes what device the code is intended for. Umm, no thanks. Not only is the name unwieldy, but when the Consumer Products division is dissolved in our biannual company reorganization the name is no longer meaningful.

Maybe I should give the robot an internal code name and use that as the library name, Robot_Homer.lvclass. The problem is that in my group the robot has been known simply as "the robot." I might call it Homer but the name doesn't have any meaning outside the context of my brain. People get irritated because they view it as unnecessarily complicating discussions. (I've tried it.)

As it turns out, I did essentially ensure a unique name by using OGB name mangling to append an acronymn of my group's informal name. Of course, the acronym is meaningless to everyone except me and it is now firmly embedded in legacy code.

-----------------

In it's simplist form the namespace could simply be string property attached to a library. When Labview attempts to load a library with the same name as a library already in memory, it compares the namespace of the library in memory with the namespace of the library on disk. If they are the same then the libraries are the same; different namespaces = different libraries. The namespace itself doesn't have to be used anywhere except when loading identically named libraries.

(One of my favorite sayings is, "If the solution seems simple I don't know enough about the problem." Obviously there are many design considerations in play I know nothing about. I don't mean to suggest the solution is this simple; I'm using this as an example to further illustrate my concept of namespaces in Labview.)

QUOTE (Aristos Queue @ Feb 10 2009, 06:26 PM)

Your questions strongly hint that R&D has been significantly off track in our work on this problem, at least as far as your situtation is concerned -- it may apply to other users as well. Let me see if I can explain why your questions disturb me...

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

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

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

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

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

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

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

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)

Name mangling while building a project breaks any vis that depend on a path constant to a vi in the project. How do you work around this?

QUOTE (AQ)

QUOTE (Daklu)

QUOTE (AQ)

QUOTE (Daklu)

QUOTE (AQ)

------ 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)

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)

The OpenG application palette have VIs to 'unmangle' or 'mangle' file names.

'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)

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)

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)

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)

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)

Another option: Stop using OpenG namespaces and instead put the whole kit and kaboodle into a LV Library to provide namespacing. If you do that, your paths aren't changed at all. You can still use OpenG to namespace that top level library if you so desire, but all the stuff inside that library retains its original path and filename.

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.

• 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)

It was going to be fixed in LV 8.6, but in LV8.5 someone wrote some new features for another part of LV that depend upon that uniqueness of name and enshrined it.

I'm really curious, what feature would break if the original bug were fixed, and can we vote on the relative value of it?