Error.txt file

[Daklu]

I really like the idea of being able to define error codes and descriptions in an error.txt file.  It's very convenient to be able to see all the errors in a single place.  However, the location the error.txt file must be stored, to be blunt, stinks.  Instead of storing them in user.lib\errors (which creates a useless palette item) how about putting them in user.lib\_errors?  It would also be nice if the Error Cluster from Error Code VI had an optional filename input to define which error.txt file to use when looking up the error.

[AristosQueue (NI)]

a) There are four locations where you can put error codes, including next to your built application/project file for errors that are specific to one app.

b) Error Cluster from Error Code VI isn't the one that would need the input. General Error Handler.vi is the one that would need the input. The error code cluster doesn't record the reason for the error, only the source and the error code. The code is translated using the error text files only at the error handler. 

c) There shouldn't be a palette item created for the error code text files. I'll file a CAR about that. 

[Marc Blumentritt]

@ Aristos Queue:

Concerning a): Where are these four locations? Where can I read about this?

Thanks for any hint.

Marc

[Daklu]

AQ -

I'm thinking more about error codes for reuse libraries, not built applications.  I've used the General Error Handler vi in the past for raising errors in reusable code.  Wrapping the error code and description arrays in a VI is the best way I've found to centralize them, but I was hoping to be able to use the Error Cluster from Error Code since it provides better information when probing the error wire and the error.txt file is an easy way for library users to find information on the errors the library will raise.

A palette item isn't created for the error.txt file, but since it's put in user.lib\errors, a palette is created for the directory.

[RandyP]

@ Marc:

I think this is what you're looking for. I notice it doesn't seem to say anything about files in the project's directory, however.

http://digital.ni.com/public.nsf/allkb/6077DBEDA4F9FEE3862571F600449501

[AristosQueue (NI)]

---

RandyP wrote:
I think this is what you're looking for. I notice it doesn't seem to say anything about files in the project's directory, however.

---

A) I thought one of the directories we checked was next to the project, but it isn't. My mistake. If you build an application, we check next to the built app.  Since I thought we were already including in the list of paths that we check the path to the .lvproj file, I never brought it up to anyone before. Now that I've realized we don't, I'll make the suggestion. I don't think it would break any existing code, and I think would be a very good idea. If built apps can have custom error codes, why not development? Now having said that...

B) ... adding the .lvproj dir doesn't help Daklu's use case of error codes specific to reuse libraries. Now, the original design (six years ago, I think) was that anything you were going to reuse among many projects (and this predates the introduction of the .lvproj files themselves) would be located in user.lib. You'd install it there and as part of installation you'd put the error code files into place. That sort of deployment structure is probably antiquated. I don't have a good idea off the top of my head for how libraries would contribute specific error codes to the system. Might be worth thinking about, but my plate is full these days. 

C) I filed a bug report against that document... you'll notice that under the development environment there are 4 directories listed. Two of them are identical. One of those duplicates should actuallly be "C:\Program Files\National Instruments\Shared\Errors" (or similar location on Mac/Linux).

Here are the directories we check in the development environment (Windows -- Mac and Linux are similar):

C:\Program Files\National Instruments\<lvversion>\resource\errors

C:\Program Files\National Instruments\<lvversion>\resource\errors\<language>

C:\Program Files\National Instruments\Shared\Errors

C:\Program Files\National Instruments\Shared\Errors\<language>

C:\Program Files\National Instruments\<lvversion>\project\errors

C:\Program Files\National Instruments\<lvversion>\project\errors\<language>

C:\Program Files\National Instruments\<lvversion>\user.lib\errors

C:\Program Files\National Instruments\<lvversion>\user.lib\errors\<language>

Here are the directories we check in a buit application (Windows -- Mac and Linux are similar):

C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\<lvversion>\errors
C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\<lvversion>\errors\<language>
C:\Program Files\National Instruments\Shared\Errors
C:\Program Files\National Instruments\Shared\Errors\<language>
<path to my application>\project\errors
<path to my application>\project\errors\<language>
<path to my application>\user.lib\errors
<path to my application>\user.lib\errors\<language>
 

[Darren]

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.