Executable cannot find custom error code file

[PaigeT]

I am building an application in LabVIEW 2013 on a Windows 7 computer and deploying it on a Windows XP computer. My application has a custom error code file, stored in <user.lib>\<Application Name>-errors.txt, but my executable on the Windows XP machine can not find the custom error file and only returns the call chain for any errors that occur. 

When not using an installer, I have tried copying the error code file to all of the locations listed here: http://digital.ni.com/public.nsf/allkb/6077DBEDA4F9FEE3862571F600449501 but the application still does not load the custom errors. I do have the box checked for "Include custom error codes" in the build specifications. 

When building an executable and bringing it from Windows 7 to XP, where should I be putting the custom error code file? Is it looking for it in Program Files (x86), but not finding it because it's XP? 

[JÞB]

Its probably because you are not using an installer.  I have never tried to deploy custom errors without one.

[PaigeT]

I've tried it both ways. And using an installer is a huge pain because I have to change the privileges on the deployment machine, which already has the run time engine and all the correct drivers, it's not convenient to keep building an installer during debug when all I really need is the executable. So I just need to know where the executable looks for a custom error code file. 

[JÞB]

it appears possible:

When building an executable (EXE) or shared library (DLL) with the Application Builder, make sure to add the custom error file as a support file (under the Source Files tab). For an executable, the custom error file will be saved in the <executable destination directory>\user.lib\error

seen here

This makes me suspect that the appbuilder keys somthing in the exe to let it know to look in the \error directory (But probably only if there is a properly formatted xxx-errors.txt file always included.)

[PaigeT]

I have seen that page and it's from 2006, so I think it's outdated. There is no section for support files in the source files tab of the application builder for LV2013, but I have the error code file, properly formatted since I built it from LabVIEW's error code edit box, listed as "Always included" in my executable. 

[JÞB]

---

@PaigeT wrote:

I have seen that page and it's from 2006, so I think it's outdated. There is no section for support files in the source files tab of the application builder for LV2013, but I have the error code file, properly formatted since I built it from LabVIEW's error code edit box, listed as "Always included" in my executable. 

---

Well, you might need to add the destination manually.

[PaigeT · Accepted solution]

It's been a few months since I originally posted this question and I'm not sure if anyone cares about this followup, but the solution I found was to put the custom error code file into <Program Files Folder>\National Instruments\Shared\Errors\English\

There are other locations that the run time engine will check for custom error codes (I tried all of the ones listed above), so if the same error codes exist in 2 locations the error popup will show both error messages. For built-in error 1 it looks like:

LabVIEW: An input parameter is invalid. For example if the input is a path, the path might contain a character not allowed by the OS such as ? or @.
=========================
NI-488: Command requires GPIB Controller to be Controller-In-Charge.

So if you have a custom error code file and it exists in 2 locations that LabVIEW RTE checks for error codes, you'll get the same message before and after the ===============

Listing the error file as "always included" when building the executable or checking the box to include error files did not do the trick, obviously. Unless you are creating an installer to distribute the application, the error code file must be manually moved. The Shared\Errors folder works best for me because it is a location that makes sense. 

Also, don't worry - it didn't take me 5 months to figure this out, I just didn't think to update all of my loyal followers (ha) with a solution.