Make custom error code files part of a project

[Jeff-P]

I decided to dive into the world of custom error rings, andit is a clean way to implement customized errors throughout a project.

That being said, forcing the custom error file to be in the user.lib folder makes this feature quite a bit less useful for me. I am working on a project with source code control and multiple developers. Since the custom error code file is in user.lib, it is not in my source code repository, and is awkward to share between developers. 

I propose that custom error codes should be a project level feature. 99% of the error codes I want to add are specific to a certain project, so I don't need them in other projects, however I do want them to distribute with my project. I understand how to distribute this with my built application, but during development it is not as easy to share.

I am proposing that the error code text editor should be in the Project menu, and the error code file should not be required to be in user.lib (allowing it to be stored in a repository and shared among developers easily).

[manu.NET]

Hi,

Look at this idea ... http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Project-error-code-files/idi-p/1071232

Manu.net

[sbus]

Yeah. Just add a local error list the same way you add a globals.vi to a project. It would ONLY apply to that project and would travel with the source files.

[HorseBattery_Stapleguy]

I think this should be a feature.

I disagree with the idea of having a globals.vi for a project. I already do this to manage certain development time constants and while that's a nice workaround... that's what it is. A workaround. A dedicated solution for managing these sort of error or project constants that must be edited during development should be as simple, clean and quick as possible.

For example, the globals.vi solution is a lot less convenient in my opinion if you wish to add format level features like those provided by the error ring unless you start managing a polymorphic instance of sorts for the "error constant" vi itself. That's a lot more tedious and slower to manage in comparison to the ease of use that would be granted by the development environment itself.

You can of course, develop tools to create and manage these things so on and on. But again, that's something that should already be part of the development toolset.

[Ajay_MV]

I agree.. The error codes needs to be local to project and controllable via SCM

[mthheitor]

Yes, we need different ways to manage the custom error codes