Develop Reference

How to block mouse click events from another form

I have a winforms single form application that uses a "Thickbox" I've created whenever the loads a new view into the application form.
The "Thickbox" shows another form in front of the application's form that is semi-transparent and has a user control that is the box itself.
This thickbox can be shown a modal dialog and in that case I have no problems at all, but it can also be shown as a non modal, for instance, when the user switches views in the main form, it shows thickbox with a loading animated icon.
The problem is that when the thickbox is shown as non modal, it doesn't block the user from clicking on the buttons of main form of the application.
When thickbox is shown nothing happens, but as soon as it's closed, the click is being processed by the click event handler of the relevant button in the main form.
I can't use ShowDialog since I can't block the UI thread, and I need to get the indication from the main form when to close the thickbox,
I can't set the Enabled property of the owner form as described in this answer (though I've tried various versions of this solution, nothing helps)
I've tried using the win API function BlockInput as descried in this answer, but that didn't block the input,
I think my best chance is using the Application.FilterMessage method, but I couldn't get that to block the mouse clicks as well.
It would be great if I could encapsulate the mouse click blocking inside the thickbox form itself, so that it would be usable easily with other applications as well, but
a solution on to the calling form would also be very much appreciated.

I'm glad to announce that the problem is finally solved.
After spending a few days attempting to recreate this bug in a new application, re-constructing the main form in the application, comment out parts of the code in the main application, and generally just shooting all over to try and find a lead, It finally hit me.
The application behaved as if the clicks on the thickbox was queued somehow and only activated when the thickbox was closed. This morning, after fixing some other bugs, The penny finally dropped - all I was missing was a single line of code right before closing the thickbox's form:
Application.DoEvents();
The annoying thing is that it's not something that's new to me, I've used it many times before including in the main application and in the thickbox code itself... I guess I just had to let if go for a while to enable my mind to understand what was so painfully obvious in hindsight...

Any way to stop focussing a WPF textcontrol slowing application update performance?

I'm developing a C# WPF XAML-based Windows desktop application, and the UI is beautifully smooth and slick until I focus a textbox. Once focussed, the update rate of the whole UI is much lower. I'd estimate it all runs at the "full" (?) 60fps originally, dropping to more like 30fps after the text control gains focus. I've dug around all sorts of Microsoft documentation and advice on WPF performance, but nothing seems to mention the mere act of a control gaining focus being a problem. It's quite mystifying. I've tried to use the Windows Performance Toolkit to analyse the issue, but I'm getting nowhere. I've been able to do a klugey workaround in some scenarios with judicious use of Keyboard.ClearFocus() when clicking any other control, which returns the update rate to normal, but it's not great to have to do that.
This issue can be readily replicated - a brand new VS2015 WPF project, with a text box and a button will show the issue (add Keyboard.ClearFocus() to the button's click handler). This demonstrates it's nothing specific to my application code, it's a framework issue.
Does anyone have an idea why the described issue may be occurring, or how I may be able to resolve it?
Update: I've uploaded a sample project showing the issue, here: http://muuh.co.uk/SlowTextbox.zip

Winforms designer misbehaving, essentially broken

We have a complicated legacy form built in Winforms that recently has started seriously misbehaving and it gets worse and worse as time goes on. Just opening the form in design view will alter the layout of the form, sometimes in minor ways (a control is resized to be a pixel smaller) and sometimes in major ways (a component is moved to X position -6582). Due to the size of this form and the nature of the generated .Designer.cs referring to the diff is almost usually useless to determine whether the changes that were made to the form were the changes that you actually intended.
Based off a number of suggestions I found in other questions:
visual studio 2005 designer moves controls and resizes Form
Visual Studio keeps resizing my form without me telling it to, help!
Controls moving in vs2008 design mode on build
AutoScaleMode is set to None. I experimented briefly with various monitor resolutions, to no avail. Ultimately we decided to stop relying on anchors and instead use a combination of TableLayoutPanels and Dock properties. And that's when the trouble really started...
After heavily redesigning one of the hairier tabs on this form, when I tried to save Visual Studio spun for 2-3 minutes and reported "Could not load file or assmbly 'MyProject, Verion=X.X.X.X, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified" (as seen here: Visual Studio 2013 Can't save, build, or rebuild solution). This happened whenever the form attempted to save. After following the advice in the accepted answer, I was able to save/build again.
Attempting to run not much later resulted in a very, very long build time and a completely empty form (as seen here: All controls on a form are invisible and https://stackoverflow.com/a/5524183/1015495 ). All calls to Controls.Add had been removed from the designer (I assume this massive change is what resulted in the long build time). I restored the form to a previous version and began recreating my changes. Now, much more insidiously, certain controls have had all of their children removed.
Working within this form is becoming a timesink at best and unfeasible at worst. The solutions that I've found online basically boil down to "recreate the form manually" or "don't use Winforms". Unfortunately neither of these are an option right now. How can we mitigate the problems that we're having with this form in the mid-term future until we can come up with a proper fix?

I am working through an almost identical problem at the moment and mine seems to be a bug in Visual Studio 2013 related to having a "linkLabel" control on a User Control, which is on one of the tabs of a tab control on the main form.
I had other linkLabel controls on the parent form that did not cause any issues. The weird thing is that not ALL of the tabs were messed up, only some of them. I can only conclude that it gets through part of the layout restructuring, hits the user control, and bombs out, failing to finish the layout correctly. I attached a second version of visual studio to try to catch exceptions, and saw various status lines showing up in the debugger, but did not see any exceptions thrown. I am not that familiar with doing that, so it's possible I did that wrong though.
I could revert the code back to after I had added the user controls, but before VisualStudio opened the form in the designer and automatically re-generated the designer code. At this point, opening the form in the designer will always cause exactly the same design failures. As long as I never opened the code in the designer again, everything would work correctly at run time.
If I removed any reference to the custom user controls with link labels, the designer would also open without any trouble. At first I assumed I had an error in my own code so I started commenting things out, but it was still happening even with just the basic elements dragged on. So then I started removing elements and adding them back one at a time to see what broke it. In my case this turned out to be the "linkLabel" control. I am not sure if there are other controls that will do this yet. For now I just plan on re-writing the code to not use a link label on the user control though and see how well that goes.

Last view superimposed on current view when double-back navigating

I do the following navigation pattern:
Navigate into the app (and it's main view)
Go into a detail view that fetches something from a REST server (that is - it shows a progress indicator for a few seconds)
While progress indicator still is shown, I click the back-button twice in quick succession (easy to do by mistake)
The app returns to the main view, but with the content of the detail view superimposed on it.
A screenshot of the resulting mess is shown below.
This was recreated both on a Nokia Lumia 800 and HTC Titan.
First of all - what the h..? And is there anything I could have done to make this happen?
There is no exceptions (or anything else) shown in the output. The only thing happening in the OnNavigatedFrom() method of the detail view is nulling out the background image (for memory reasons). It happens in other views as well.
My idea is that the draw method on both views are called on different threads, leaving only the main view to be responsive.
Any idea as to what has happened here, and how I can fix this bug?

This type of issue happened to me when using TransitionFrame from Silverlight for Windows Phone toolkit. Using transitions when navigating from page to page can cause this if the user taps on back button once or twice while the transition/navigation is in progress.
I believe it's a bug, but couldn't find it reported at the official CodePlex site of the toolkit, therefore I don't know about any reliable solution or workaround except trying to handle the back button press on the page that's causing issues. In other words, catching the back button/key press and either disabling it (I'm not sure that this would pass certification!), or simply prompting user with a MessageBox that the page is still loading and if they are sure that they want to navigate back, might work for you.
Other solution I can think of is that you avoid using TransitionFrame, but that's not really a solution, right? :)

Why would WPF render my controls twice?

I have a complex, multi-threaded WPF application which works relatively well. Sometimes the controls of a dialog gets rendered twice on different positions. The result of this is an unreadable dialog.
Below is an example of an own written popup (opaque background with buttons on it), but it also happens on normal dialogs. Can anybody help me?