Stack Overflow when adding controls across threads.

[Chinners]

Hi all, I have a bit of an issue with some code I am designing. I am trying to implement a "file open" dialog for images. There are reasons for not wanting to use the standard dialogs. Also, I want the control to remain responsive whilst displaying a the list, so a user can select "up", or another folder whilst the list of preview images is loading. To do this, I have a panel object, and my own "simpleimage" which is a simple control which has an image and a caption. I draw the a small preview thumbnail image to the simple control then add this to the panel. To keep the app responsive, the creating of these simple images is done in a background worker, and a delegate adds them to the panel. Delegate Sub AddIconDelegate(ByVal s As SimpleImage) Private Sub AddIcon(ByVal s As SimpleImage) SyncLock Me.ImagePanel Me.ImagePanel.Controls.Add(s) End SyncLock End Sub and, in the background worker: Loop through relevant images Dim Blob As New SimpleImage(MyCL, ImageTypeEnum.Image, FileName, Cap) AddHandler Blob.ImageSelected, AddressOf ImageSelectedHandler Blob.Location = New Point(xp, yp) Me.ImagePanel.Invoke(ASI, Blob) End Loop. And the scrollbar: Private Sub _ValueChanging(ByVal Sender As vScroller) Handles VS1.ValueChanging SyncLock Me.ImagePanel Me.ImagePanel.Top = -VS1.Value End SyncLock End Sub This code generally works fine. I have successfully added over 4000 images. I can mess around with the scrollbar which controls the panels position (move it up and down) and generally things are fine, BUT if I go crazy and move the scroll bar really crazily, the invoked procedure (AddIcon), more specifically the "Me.ImagePanel.Controls.Add(s)" line, will cause a StackOverflowException. This can happen with only 300 icons. So, Question time. Does anyone know why this is happening? Any way of catching the stackoverflow exception? I have tried slowing the backgroundworker down with a thread.sleep, and this reduces the chance if it happening, but does not eliminate it. The synclock also reduces the chance of this happening. Thanks in advance. Jason

[Lost User]

Hi Is there more code? maybe some eventhandlers on the imagepanel? and ther's one more thing: your syncLock is useless :) basically you're of coure right that you must lock resources when you modify them from different threads. but since you call your AddIconDelegate correctly via Invoke of ImagePanel it's executed through the main-thread of your application. so no syncLock required here. but anyway that's not the problem here... you should take a look at the CallStack in your debugger when the exceptions comes up.. maybe that gives you an idea what's called from where over and over... greets m@u

[Chinners]

Hi, Thanks for the reply. The Synclock was an attempt at curing the problem, and it does seem to reduce the problem... but then again, maybe it doesnt :-D. I will remove these lines! There isn't really much more code. The imagepanel has no eventhandlers defined by me, and its only function is that of a container to hold all the other controls. I only access its "Top" value, setting it depending upon a scrollbar position. The background worker does "report progress" which increments a progress bar on the main thread, but that is about all I'm afraid for the code in the form. The exact exception reported is rather useless (well, to me and Uncle Google): System.StackOverflowException was unhandled An Unhandles Exception of type 'System.StackOverflowException' occurred in mscorelib.dll Make sure you do not have an infinite loop or infinite recursion. I certainly dont have an infinite loop, and I cant find out where in mscorelib.dll this is occuring. Thanks again.

[Lost User]

yes that's right the message of the Exception is not really interesting.. but the StackTrace might speak books :)

[Chinners]

Hi yet again. I think I have found the problem, and the fix. I was being polite to the system, and doing an application.doevents whilst in the backgroundworker's reportprogress event, after updating the progressbar. I have removed this "polite" code, and now it is still responsive, but will not crash. This must have been a left-over from the single threaded version of the control. Thanks for your time. Jason