Note that there are some explanatory texts on larger screens.

plurals
  1. POProcessing Windows Messages in blocked UI Thread?
    primarykey
    data
    text
    <p>This is possibly related to <a href="https://stackoverflow.com/questions/6095800/progressbar-updates-in-blocked-ui-thread">ProgressBar updates in blocked UI thread</a> but is a little different.</p> <p>While troubleshooting a crashing WinForms control (a DevExpress treelist) a member of our team encountered an unusual situation, and I'm wondering if anyone can help us understand what's going on. English is not his first language, so I'm posting on his behalf.</p> <p>Please see <a href="http://i51.tinypic.com/dwdoqc.jpg" rel="nofollow noreferrer">this screenshot</a> from Visual Studio 2005.</p> <p>Note the following points:</p> <ol> <li><p>The main UI thread is stopped and is currently in a DevExpress control draw method.</p></li> <li><p>The code shown on screen is from a point earlier in the same call-stack. This code is in the data layer and was called in response to the control's request for an image to display for the tree node. (perhaps also originating from a Paint handler)</p></li> <li><p>The displayed code is from earlier in the callstack, on the main UI thread, and is currently waiting on a lock! Since remote systems can send events which are processed on background threads in the data model (i.e., data models are sync'd between client and servers), we lock to keep the data collections thread safe.</p></li> <li><p>As the callstack shows, we continued to process paint messages on the UI thread, while we would expect the thread to be blocked.</p></li> </ol> <p>This is very difficult to replicate, and I have not been able to do so using a simpler test project on my own box. When this situation arises, however, the result is that the DevExpress control's internal state can be messed up, causing the control to crash. This doesn't really seem like a bug in the control, since it was no doubt written with the assumption that these paint methods are running only on the UI thread. What we see here makes it look like the UI thread is acting like two threads.</p> <p>It would seem possible that this is merely a Visual Studio bug in the presentation of the callstack, except that this whole endeavor is resulting from an effort to troubleshoot the occasional crash of the control in the released app (in which case it shows as a big red X in the UI), so it seems the problem is not isolated to the debug environment.</p> <p>Alright, that was complicated, but hopefully made sense. Any ideas?</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

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