Thanks for the answer! Good to know that I can dig into the code and see for myself what kind of risk may it carry, and what tests should I build around it to test it if I need to do so.
are there nay plans on implementing this lib on base of the Actor Framework? IMHO this would fit quite nicely
I've discussed it with Allen, and it's something we're planning to look into. No ETA on it though. Of course, the source is provided, so if you're feeling ambitious you could always take a crack at it
I feared you'd make that DIY suggestion
I just downloaded the latest version of the SEH and was using the "Repeating Error Handler" and CEH templates that ship with the SEH. It looks like the "Priority" configured in the Express VI is incorrectly being compared to "Number of Notifications per Priority" as set in the CEH.
In other words:
1. In the CEH I have "Number of Priorities" set to 3.
2. In the CEH I have "Number of Notifications per Priority" set to 5.
3. The Express VI throws error 537602 only if I set "Priority" to 5 or more. I think it should throw an error if I set the "Priority" to 3 or more.
4. If I set the Priority in the Express VI to 0-2, the CEH responds as expected.
5. If I set the Priority in the Express VI to 3-4, the CEH doesn't do anything.
A couple of other things which are not bugs necessarily but really should be changed:
1. The Tip Strips for some of the controls in the Express VI Configuration Dialog box are misleading or incorrect.
2. The "VI to Call" input requires that the ".vi" extension be included. The Express VI should figure out to add the ".vi" extension if it is missing.
3. Since the "Loop?" output of the Express VI is TRUE when we WANT an iteration to occur, the Conditional Terminal of the While Loop in the "Repeating Error Handler" snippet VI should correspondingly be set to "Continue if TRUE" and not "Stop if TRUE".
The configuration for a given instance of the SEH node is stored within the scripted subVI that is created when you drop it. The XML files serve as an easy way of creating templates for error behavior, for example, if you want to have the same or similar configuration in many different locations in your project (they also made my life much easier when I was testing it, as I didn't have to manually reconfigure the test cases every time).
There is no link between an SEH node and the XML that was used to configure it (important, as the XML files are not a way of slaving many different nodes to a central configuration, I considered that, but was unwilling to accept the deployment complications and performance tradeoffs it created). To that end, you don't have to deploy the XML files in any way. You can save them with your source and/or add them to your project for organization purposes.
I would like to use the SEH to manage specific errors, but can it also be use to manage generic errors? If I generate a managed error, it will be managed correctly, but if labview throw an error that is not manage in the SEH, the errors won't be catch by the Central error template.
How can I automatically classify unmanaged errors?
This seems to be a brower or OS specific issue. It may take us a couple of days to address this with the Thanksgiving holiday. Here are the direct links to the downloads from the page.
|Any attached Code is provided As Is. It has not been tested or validated as a product, for use in a deployed application or system, or for |
use in hazardous environments. You assume all risks for use of the Code, and use of the Code is subject to the Sample Code License.