Is there a way to reread error files without restarting LabVIEW?

[RFTMS]

If there is not, there definitely should be. It is stupid to have to shutdown and restart the tool during development.  I wonder just how much engineering time has been wasted over this?

While I am dancing on my soapbox, what about DLLs?  Is there a way to reload DLLs without exiting LabVIEW? 

[CharlyStardust]

Hi RFTMS,

You don't need to exit LabVIEW during development.

You can simply stop your application with a property node.

I enclose the property node.

Charly

[RFTMS]

Charly,

You totally missed the point.  The point is that when using -errors.txt files to define user-defined errors, LabVIEW must be restarted for it to include any newly defined errors.  I say this is totally unaccepatble.  NI needs to fix this or I need to learn the work-around.

RFTMS 

[smercurio_fc]

---

You don't need to exit LabVIEW during development.

You can simply stop your application with a property node.

I enclose the property node.

Charly

---

How exactly does that solve the problem? All that does is abort the app (which is a BAD thing to do unless you are really existing the application), or stop the VI in which the Close function is in, which is completely pointless. 

To the poster: This is why I don't use those files. The error codes database is housed inside of the General Error Handler, and there seems to be no way of reinitializing that database at will. That's why I use my own error codes file and read in error codes at will and have my own error handler. In your case you don't really need to go that far. Presumably somewhere you're calling the General Error Handler. That function has separate inputs for user-defined error codes and descriptions. Thus, you can read in your error codes and descriptions as arrays and simply feed them to the General Error Handler. If you use the General Error Handler in many places simply write a wrapper VI for it, and use the wrapper instead. 

You can submit a product suggestion at the Product Suggestion Center.  

Message Edited by smercurio_fc on 09-15-2008 01:27 PM

[RFTMS]

This is why I have gone to a database approach.  I use a MySQL database (labview_errors_warnings) with an error table from -8000 (Base User-Defined Error Code) to -8999 and a warnings table from 5000 (Base User-Defined Warning) to 5999.  This use of positive vs. negative values is consistant with CVI. Of course,  negative values are critical, if not fatal, and positive values are informational and quite useful at times.

This is an issue when I am doing work for people who don't want the added complexity of the 3rd-party application, MySQL, installed on their client.  Or, it means that I have to distribute, install, and configure the ODBC service provider (MySQL, including privileges and System DSNs) for every application.  An XML file would be much easier, as I am sure your single text file is easier.

Thank you for your suggestion.  I did submit my suggestions to NI. 

[smercurio_fc]

Actually, I do use an XML file.  It's just my own format, and it stores other information besides just error codes. There are also configuration parameters that control how error handling is done, such as ignoring certain errors or certain error types, logging, and advice for errors. My custom error handler simply merges the error code descriptions provided by the General Error Handler with the ones in my file. If you do a search for error handling you'll find that Tushar had posted his error handling library. You might want to take a peek at it to see if you can get some ideas.