The Build dialog disappears and the beach ball just spins with Xojo using 100% CPU time. The only major difference made to the code that may have caused this was adding a new worker. It runs fine in debug. It is repeatable on other computers and on both Xojo r1.1 and r2.
Has anyone experienced this before?
Thanks Chris
What optimization level?
If you remove the new worker, does it work?
Can you create a private Issue with your project for Xojo to test?
Thanks very much Alberto. Yes, I have removed the worker and the project builds normally. Optimisation is set to Default. If necessary, I will make the project available, but for now, I’m hoping someone might have a something for me to try without doing that as the project is company code.
In the debugger, workers are run as normal threads. As such, there can be a number of issues, probably with project items shared with the worker, that a thread will tolerate but a worker won’t.
Ultimately, the inability to reliably debug a project with a worker is a Xojo issue, and a concerning one.
I’m curious what you mean by this. The whole reason that the workers are rendered as Threads in debug mode is so that you can debug them. If Xojo didn’t do that, there would be no easy way to get the debug information back to the IDE. Not to mention that because they are a completely different process, you could have breakpoints in multiple threads all being hit at the same time. Their use of cooperative threads for easy debugging is quite ingenious in my opinion.
Thanks Jerry. Yes, I’m aware it’s not a true test of the worker in debugger because of threading. I still have two other workers (included in the working project) who all share the same project items. I believe it might be a reference I’m making within the failing worker that is outside the project alright so I’m commenting out code at the moment to see if I can narrow it down. A bit painful as I have to force-quit on each failure and then re-open Xojo and the project which all takes a lot of time (for this project about 5 mins each time)
Literally the first test I did with workers was fine for threads and hung when built. Anything that works differently in the debugger compared to the built app is not a good idea ™. Together with the missing error handling this means that workers as just a buzzword.
I know from experience that it is possible to make the debugger happy, but gag with a “real” worker in a built app. One example is if a class is shared with the worker that has any references to UI controls, even if the worker doesn’t use that code. Somehow it doesn’t throw a ThreadAccessingUI exception. Another one, a little more subtle, is if the code calls a public method in App.
Make no mistake, such bugs were mine, but the debugger did not help.
I also have a Windows-specific issue with one project, which again works fine when run in the IDE—but that’s another story till I can reproduce it in an example and file the issue. 
Hi Jerry (et al). Just to confirm. The cause of the hang was, indeed, an external constant, which I mistakenly thought was referenced. It’s disappointing that, a; the debugger doesn’t test for project items not referenced and b; I had to spend so many hours going through the code, hang after hang after hang.
Thanks again for your suggestions
Chris
That is why console should be included in DeskTop (as it used to be) and the whole "worker’ functionality have been build around that (as well as providing an X-Platform shared memory API!)
-Karen