Asynchronous "General Error Handler"?

[OneOfTheDans]

I'm developing an application where the central controller caches errors until the user specifically opens it. I like using the General Error Handler for its native UI and the extra details it adds. But my central controller directs other traffic too, so it can't block waiting for the General Error Handler. So I wrote this code to launch the General Error Handler asynchronously, which works.

Has anyone else done this sort of thing?

Am I on the right path, or over-complicating the whole thing?

Will this work in an EXE even though the path & "type" are pointing to specific files?

[Kyle97330 · Accepted solution]

It might not be a great idea but I can tell you that you definitely want to ditch the constants (path and connection pane) to make it work in an EXE.

Instead, use a Static VI reference node, linking that to the error handler VI.  You can right-click the static VI reference node to make it a Strict reference and use that instead of the connection pane constant, and you can use either the VI Name or VI Path property nodes on the VI reference to get the wire to pass into the Open VI reference.

[James_W]

Actor Framework - of course you're complicating it 🤣

Basics:
Take the Error Data and pass it to a separate error module, then you can determine what to do with it.✔️

If you launch General Error Handler (with a dialog) and get lots of errors you're going to kill your application as you won't be able to launch the dialog as fast as you can generate the errors.
You'd be better with a simple UI with the errors in a table and the option of logging the errors to a file.
(If you manage to create a timeout error in your app every 100ms, and send it to this as it stands, you'll never catch up with the button pushes to close dialog and then the program, and drive yourself crazy)😁

James

[OneOfTheDans]

---

@Kyle97330 wrote:

Instead, use a Static VI reference node

---

This is just what I needed, thank you! It's basically my first time opening VIs by reference and I thought Static VI references were what I was already doing (the static/hardcoded paths).

---

---

---

@James_W wrote:

Actor Framework - of course you're complicating it 🤣

Yes, I question myself about it almost every day - but it solves almost as many problems as it creates! 😛

---

@James_W wrote:

you're going to kill your application as you won't be able to launch the dialog as fast as you can generate the errors

---

---

This asynchronous popup isn't inline with error generation. I am storing all the errors in a table like you suggested. The user can double-click one of the errors to see the full details in a popup. I like your idea to make a separate module (Error Actor) that manages the table & popups. But still, I think the popup should be asynchronous so the table can update if new errors come in while the user has the dialog open.

Thank you both for the good answers!