AlexZakharov

I have an odd problem, please bare with me. We have a main app window (very heavy multi-grid frontend with background threads etc) from which we can spawn a child non-modal borderless transparent form. The child form has a tab control and a ToolStrip control. By clicking on various toolstrip items either a new forms popup or the main gui form is updated.

In 99% of the cases everything works as expected. But once in awhile (very very difficult to duplicate) we get a situation where the child form becomes visually unresponsive, yet functional. In other words one can still click on ToolStrip items and mouse clicks are processed as expected (e.g new forms are spawn), yet the clicked toolstrip item doesn't change its visual state. Also, the built-in ToolStrip rollover effects dont show anymore as you move the mouse over toolstrip items. Finally clicking on a tab control within the child form may take 40-50 seconds to process. (The tabs actually don't contain anything or dont do anything so tabswitching should be instantenous). That said the main GUI form and all other forms are totally fine - they are perfectly responsive and repaint themselves as expected.

Can somebody speculate as to what could be the possible conditions under which a behavior like this can manifest itself

ps my original theory was that it may have something to do with not calling BeginInvoke but we were very careful with multi-threading and I verified that all updates to the child form are done on the main GUI thread.



Re: Windows Forms General events are fired but the form looks frozen

nobugz

A classic way to get this behavior is to Invoke/BeginInvoke() from your background thread too frequently. More than several hundred times per second will freeze the message loop, it is doing nothing but dispatching invoke requests and doesn't get around the normal paint event processing.





Re: Windows Forms General events are fired but the form looks frozen

AlexZakharov

Fair enough. But in our case the main window and all other forms are fine - only one form exhibits the behavior I described. Since all our forms share the same message loop I have to assume that it is not saturated at a time when the behavior manifests itself.





Re: Windows Forms General events are fired but the form looks frozen

Vineed

Hi

Is the form in question trying to access some resources or doing some processes which may be locked, or even deadlocked

Check it out if possible

Regards

Vineed





Re: Windows Forms General events are fired but the form looks frozen

Rong-Chun Zhang - MSFT

Hi AlexZakharov,

We are changing the issue type to ˇ°Commentˇ± because you have not followed up with the necessary information. If you have more time to look at the issue and provide more information, please feel free to change the issue type back to ˇ°Questionˇ± by editing your initial post and changing the radio button at the top of the post editor window. If the issue is resolved, we will appreciate it if you can share the solution so that the answer can be found and used by other community members having similar questions.

Thank you!






Re: Windows Forms General events are fired but the form looks frozen

AlexZakharov

Sorry for the delayed response - I changed the question back to 'Question'.

OK, so yes there are a few threads running and yes we are dealing with shared resources and we may have deadlocks. I don't think we do, but yes it is possible of course. Before I start checking and digging deeper I'm trying to get a sense of what I'm looking for. Specifically what is our theory If there is a deadlock - why does the guilty form correctly process mouse_up/mouse_down events Mouse events happen on GUI thread, painting also happens on GUI thread. I assume that if events are processed, then GUI thread is not deadlocked... And if it is not deadlocked - why doesn't repainting occur - the form looks totally frozen.

Thanks again, any theories/explanations would be much appreciated.

Alex





Re: Windows Forms General events are fired but the form looks frozen

Vineed

Hi Alex,

From what you have just said the chances of a deadlock seems remote. You said that some child forms open or some visual changes take place in the main form. Is it possible that some of the child forms have something (like loading data from database or doing some processes) that might consume lot of memory or process time and hence it takes time to load. Also, if it is possible to replicate the scenario (though it might not be easy) under which you face this problem then try putting some MessageBoxes or try debugging so that you can understand actually what happens with the events.

Good Luck

Regards

Vineed





Re: Windows Forms General events are fired but the form looks frozen

AlexZakharov

Vineed,

That is exactly what is so puzzling - all other child forms and the main GUI are perfectly responsive and are repainting fine. There is only one guilty child form that processes events but doesn't repaint.

Another interesting thing to note is that ToolStrip rollover effects on a guilty form are not happening! Those rollover effects typically happen even if the child form is not in focus. Yet I can click on the toolstrip buttons and events are fired. The fact that rollover effects (which are pretty low level and are built-into ToolStrip controll) are not happening leads me to believe that there is something very wrong with that form when it is in that state.

Anyway, naturally I would love to be able to duplicate but in the last 3 weeks it happened twice which makes it kinda difficult.

Thanks for the input though,

Alex





Re: Windows Forms General events are fired but the form looks frozen

Vineed

Hi Alex,

From your last post what I think is that in the form load event of the child form in question, there is some process that seems to be taking time. Also this process seems to asynchronous as the events of the form (like Toolstrip, etc) are being fired.

For the little knowledge that I have (Because I an ASP.Net developer), I think initialisation and paint event of the controls on a form occurs on the form init event and thats why you are able to see the controls painted and their events executed. In the page load event there might be something thats blocking the process to be completed or the process goes on to an infinite situation (maybe something like a while loop or some data from DB that is retrieved is very large for it to be databaound to a control) then it might take time. If this situation happens again try waiting for sometime and check if the things work out. Also try checking out the form load event of the child form ( or the event at which the you start experiencing this problem).

Good Luck

Regards

Vineed





Re: Windows Forms General events are fired but the form looks frozen

AlexZakharov

Vineed,

Thanks, but I'm not sure that form initialization is the culprit here. We dont rely on Form load event at all and in the constructor of the form we dont do anything time consuming either. More importantly in the 2 times that the problem occured the form would START out fine (painting is fine as is event processing) and painting would start malfuncting at a later time.

I will continue investigating and post an update if/when I find something.

Alex





Re: Windows Forms General events are fired but the form looks frozen

sirjis

It's probably not your problem, but I have encountered some strange behavior myself if I add controls to a form and then remove them from the Controls collection, where some event was still trying to be propagated to the control but for some reason it was unable to process it, so it froze the GUI thread. But again, since the rest of your message loop in the other forms is working fine, it's probably unrelated. Just something you might want to consider.





Re: Windows Forms General events are fired but the form looks frozen

AlexZakharov

OK, I figured out what causes the problem - setting transparencyKey on the Form! Setting that transparency key causes the form to be repainted EXTREMELY slowly which gives the illusion of a frozen form. The problem only manifests on certain machines - T60 dual-CPU laptops.

Anyway I duplicated the error in a separate trivial app and started a new more focused thread on this http://forums.microsoft.com/msdn/ShowPost.aspx postid=2015662&isthread=false&siteid=1