0

So I'm quite new to C#, but I'm working on a rather large threaded application that has been deciding to lock up.

I'll either be clicking a button to just launch a new form, or trying to resize a table, and it will lock up and I have to quit the program.

Does anyone have any ideas on how I can debug? If I just click Break All it takes me to Application.Run(Forms.AllForms.MainForm); which isn't very helpful.

Bit new to Visual Studio (I'm an Obj-C dev) but are there debugger options that would let me step back to see the call stack that may indicate why this is happening?

I'm also using Krypton Components, not sure if that matters.

Thanks in advance!

Geesu
  • 5,928
  • 11
  • 43
  • 72
  • One thing I'm wondering, should other threads be accessing UI elements? Would that cause this problem? (Because my app does this some) – Geesu May 02 '12 at 16:40
  • Other threads should not in any case access the UI, ever. You can do that, technically, but it is a very bad practice and you should avoid it at any cost. You should probably switch to BackgroundWorker instead of threads and access the UI in ProgressChanged or WorkComplete events, that you'll invoke from the worker's work method. – SimpleVar May 02 '12 at 16:59
  • Does the use of BackgroundWorker not require me to set up delegates (with Invoke) for updating UI elements? – Geesu May 02 '12 at 17:37
  • Not quite. You provide delegates to the actual Work method of the BGW, to a ProgressChanged method (optional) which will be invoked from within the Work method using `bgw.ReportProgress(percentsDone);` and to a WorkDone method (optional) which will be invoked when the Work method completes for any reason. The Work method will be considered as a separate thread, however the ProgressChanged and WorkDone methods will be called on the main thread. – SimpleVar May 03 '12 at 00:46

1 Answers1

2

You probably have some heavy work on the main thread instead of a separate thread someplace.

The easy way would be to put a breakpoint on the button click event and press it, then slowly go through the code, see if there is anything that should be threaded and isn't, or an infinite loop of some sort.

Post some of your code and explain about the program, if you don't mind, so we can help you better.

SimpleVar
  • 14,044
  • 4
  • 38
  • 60
  • It's not just one button click though, it's in odd places. And the background threads continue running the UI just locks up. Is there a way I can "break" on the UI thread and then see the call stack? Trying your suggestion now on the button. – Geesu May 02 '12 at 16:58
  • Find out a scenario when this occurs and investigate to that direction. – SimpleVar May 02 '12 at 17:00
  • And again, if you post your code, and even upload your full application, as you said it is all messy, it will be easier to direct you to the solution. – SimpleVar May 02 '12 at 17:01
  • So in one case I found the issue was a thread was updating a ListBox. Should I just run my app like normal and set Control.CheckForIllegalCrossThreadCalls to true? Then check every exception + verify it's not updating the UI from another thread? I'm fairly certain that's the problem. And unfortunately I can't upload the source :/ – Geesu May 02 '12 at 17:04
  • OK I narrowed it down to a .show while stepping through on a form. The first 2 times I load the form it's fine, but then the third time it locks up - any ideas? – Geesu May 02 '12 at 18:11
  • It's hard to tell without some code to look at. I'd suggest replacing all threads with `BackgroundWorker`s first thing, after reading on how exactly BGW work (my comment to your questions sums it pretty concisely, although examples are the way to go, usually), and see if the problem had been solved by itself. In any case, do not set CheckForIllegalCrossThreadCalls to true. If there are still errors, you can add debug prints using `Debug.WriteLine(...)` to help you understand the flow of events, and perhaps the root of your problem. – SimpleVar May 03 '12 at 00:50