Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Nicholas Piasecki's answer sheds a lot of light on this problem for me. I've often had this odd bug and I appreciate the information as to why its occurring (Handle for a control probably being lazy-loaded on first call to this.InvokeRequired from a background thread)</p> <p>Im creating a lot of UI dynamically (on the UI thread) and binding to presenters (MVP pattern) which often start worker threads before the UI has first show. There are of course updates to the UI and these are marshalled onto the UI thread using this.InvokeRequired/BeginInvoke, however at this point I assume a handle may be created on a worker thread.</p> <p>For me the cross-thread violation is occurring in the MainForm dispose method, when the user closes the app. As a workaround I recursively iterate through child controls disposing of them and their children when the main form is closed. Then reducing the list of controls I disposed, I eventually narrowed it down to a single control that was causing the access violation. Unfortunately I wasn't able to solve the problem directly (calling CreateControl() or CreateHandle() on the control in question did nothing to resolve the problem), but I was able to work-around by leaving my recursive disposal in place on app shutdown. </p> <p>Why this works and the built-in Form.Dispose() method doesn't I don't know. </p> <p>Anyway I will be more careful in future when creating controls near worker threads, now I know the Handles are lazy-loaded, so thanks!</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload