Just a short story
-
I was adding an interesting unit test today, using my unit test engine (so don't expect this to be relevant to anything else). My unit test engine runs unit tests in their own thread, so the UI remains responsive. The code to start the unit test is:
ThreadStart runTests=new ThreadStart(RunTestsThread);
Thread t=new Thread(runTests);
t.IsBackground = true;
t.Name = "TestRunner";
t.Start();Now, the test I was writing was emulating user interaction on a form. Not your typical unit test, because usually one just tests methods, but in this case I wanted to get some idea of how many operations per minute I could do going through the UI and dealing with all that that entails--loading the forms, loading up the data, running the workflows, etc. All was going well, when I got this error message setting up a combobox. The error message was the dreaded (haha) "you have to use the STAThread model, please add STAThreadAttribute" to your Main method. But the odd thing was, it didn't happen when the unit test loaded the main form. It happened when the unit test ran the workflow to load up a child form! And checking, there's a
[STAThread]
attribute on the Main of the unit test engine.So that wasn't the answer. I'm sure it's obvious to you (especially since I pretty much gave you all the relevant information) but it took me a while to even remember that the unit tests were being run in their own thread. And then I though, hmmm, are you able to set the apartment model in the thread? Because I vaguely remember something about that from perusing the Thread properties once, ages ago. And sure enough, yup, this line:t.SetApartmentState(ApartmentState.STA);
Fixed the problem! So, from my perspective at least, this was a subtle bug, because I had to remember how my unit test engine works (I haven't touched it in years), I had to get an inkling that you could set the apartment model for the thread, and I still am not clear on why this was happening on the loading of the child dialog and why it didn't show up on the main dialog. Funny how the previous subtle bug had to do with apartment models as well! Marc
-
I was adding an interesting unit test today, using my unit test engine (so don't expect this to be relevant to anything else). My unit test engine runs unit tests in their own thread, so the UI remains responsive. The code to start the unit test is:
ThreadStart runTests=new ThreadStart(RunTestsThread);
Thread t=new Thread(runTests);
t.IsBackground = true;
t.Name = "TestRunner";
t.Start();Now, the test I was writing was emulating user interaction on a form. Not your typical unit test, because usually one just tests methods, but in this case I wanted to get some idea of how many operations per minute I could do going through the UI and dealing with all that that entails--loading the forms, loading up the data, running the workflows, etc. All was going well, when I got this error message setting up a combobox. The error message was the dreaded (haha) "you have to use the STAThread model, please add STAThreadAttribute" to your Main method. But the odd thing was, it didn't happen when the unit test loaded the main form. It happened when the unit test ran the workflow to load up a child form! And checking, there's a
[STAThread]
attribute on the Main of the unit test engine.So that wasn't the answer. I'm sure it's obvious to you (especially since I pretty much gave you all the relevant information) but it took me a while to even remember that the unit tests were being run in their own thread. And then I though, hmmm, are you able to set the apartment model in the thread? Because I vaguely remember something about that from perusing the Thread properties once, ages ago. And sure enough, yup, this line:t.SetApartmentState(ApartmentState.STA);
Fixed the problem! So, from my perspective at least, this was a subtle bug, because I had to remember how my unit test engine works (I haven't touched it in years), I had to get an inkling that you could set the apartment model for the thread, and I still am not clear on why this was happening on the loading of the child dialog and why it didn't show up on the main dialog. Funny how the previous subtle bug had to do with apartment models as well! Marc
Not so much subtle, more a royal PITA.
Deja View - the feeling that you've seen this post before.
-
I was adding an interesting unit test today, using my unit test engine (so don't expect this to be relevant to anything else). My unit test engine runs unit tests in their own thread, so the UI remains responsive. The code to start the unit test is:
ThreadStart runTests=new ThreadStart(RunTestsThread);
Thread t=new Thread(runTests);
t.IsBackground = true;
t.Name = "TestRunner";
t.Start();Now, the test I was writing was emulating user interaction on a form. Not your typical unit test, because usually one just tests methods, but in this case I wanted to get some idea of how many operations per minute I could do going through the UI and dealing with all that that entails--loading the forms, loading up the data, running the workflows, etc. All was going well, when I got this error message setting up a combobox. The error message was the dreaded (haha) "you have to use the STAThread model, please add STAThreadAttribute" to your Main method. But the odd thing was, it didn't happen when the unit test loaded the main form. It happened when the unit test ran the workflow to load up a child form! And checking, there's a
[STAThread]
attribute on the Main of the unit test engine.So that wasn't the answer. I'm sure it's obvious to you (especially since I pretty much gave you all the relevant information) but it took me a while to even remember that the unit tests were being run in their own thread. And then I though, hmmm, are you able to set the apartment model in the thread? Because I vaguely remember something about that from perusing the Thread properties once, ages ago. And sure enough, yup, this line:t.SetApartmentState(ApartmentState.STA);
Fixed the problem! So, from my perspective at least, this was a subtle bug, because I had to remember how my unit test engine works (I haven't touched it in years), I had to get an inkling that you could set the apartment model for the thread, and I still am not clear on why this was happening on the loading of the child dialog and why it didn't show up on the main dialog. Funny how the previous subtle bug had to do with apartment models as well! Marc
Hi Marc! Might I humbly suggest using SafeThread instead of Thread for this? SafeThread automatically sets ApartmentState on Start, in addition to trapping unhandled exceptions and signaling completion. Good luck!
Best regards, Steven A. Lowe CEO, Innovator LLC www.nov8r.com
-
I was adding an interesting unit test today, using my unit test engine (so don't expect this to be relevant to anything else). My unit test engine runs unit tests in their own thread, so the UI remains responsive. The code to start the unit test is:
ThreadStart runTests=new ThreadStart(RunTestsThread);
Thread t=new Thread(runTests);
t.IsBackground = true;
t.Name = "TestRunner";
t.Start();Now, the test I was writing was emulating user interaction on a form. Not your typical unit test, because usually one just tests methods, but in this case I wanted to get some idea of how many operations per minute I could do going through the UI and dealing with all that that entails--loading the forms, loading up the data, running the workflows, etc. All was going well, when I got this error message setting up a combobox. The error message was the dreaded (haha) "you have to use the STAThread model, please add STAThreadAttribute" to your Main method. But the odd thing was, it didn't happen when the unit test loaded the main form. It happened when the unit test ran the workflow to load up a child form! And checking, there's a
[STAThread]
attribute on the Main of the unit test engine.So that wasn't the answer. I'm sure it's obvious to you (especially since I pretty much gave you all the relevant information) but it took me a while to even remember that the unit tests were being run in their own thread. And then I though, hmmm, are you able to set the apartment model in the thread? Because I vaguely remember something about that from perusing the Thread properties once, ages ago. And sure enough, yup, this line:t.SetApartmentState(ApartmentState.STA);
Fixed the problem! So, from my perspective at least, this was a subtle bug, because I had to remember how my unit test engine works (I haven't touched it in years), I had to get an inkling that you could set the apartment model for the thread, and I still am not clear on why this was happening on the loading of the child dialog and why it didn't show up on the main dialog. Funny how the previous subtle bug had to do with apartment models as well! Marc
fter hours and hours of searching for the error, it's ussually just a single line Happens to all of us.