Leaderboard

Put the entry "HideRootWindow=True" into the ini file for the executable.

Look at the error handling requirements section of the example CLA exams: ftp://ftp.ni.com/pub/gdc/tut/cla_sample_exam_atm_machine.pdf Also there are some example exams and answers on this NI page. http://www.ni.com/gate/gb/GB_INFOCLAEXMPRP/US Do the work that covers the requirements. I'd recommend a separate running code module, but a FGV may meet all the requirements depending on how it is implemented.

Not if it is done right. Either have a circular buffer of errors as a history, only show the last error, or cache the errors to disk. That's a fine idea but it doesn't scale well to large applications. You now have this inherit coupling between the error handling code, and the UI that the user sees by passing control references around. It reduces modularity, but in a pinch works fine. I probably wouldn't do that in the CLA, and am unsure how it would score using that technique

Sure blocking in these situations are fine, but for me many of my tests run for months unattended, and having a prompt come up and ask what the user wants to do, may leave the DUT in a weird state for a long time that could be dangerous, or at least invalidate the rest of the test. Prompting to continue is not something I do often, and usually it is only in the part of the application where I know the user should be there. Like if the user is setting up a test and they forgot to configure something I will prompt them to continue or go back and fix it. In this case a dialog is fine, but mid test is a poor place for a dialog in my applications.

There's lots of solutions, and anything I'm going to suggest might work or might not work depending on other factors about the design I'm unfamiliar with. For you number 1 issue in my designs the central error handler is a parallel running loop that doesn't halt the rest of the application asking the user if they want to continue or abort. My dialog just informs them of when the error happened, what the error was, and where it came from. My other code modules are written in a way that they should retry what they were doing, by reconnecting, or to go into an inert state where they only send some type of reset command to the hardware they are talking to. In neither case does the error dialog block anything. If you are using a FGV with a dialog, then that will block the flow of data which it sounds like youi don't want. For your number 2 issue I've seen something like a variable that gets incremented for every code module (actor) spun up, and then decremented for every code module that shutdown. Then only when this value is 0 does the error handler loop shutdown.