We have a fairly advanced windowing system for the app I’m developing, and one of the side effects is that when using controls inside a Popup control, the keyboard focus does not always behave correctly for the controls inside the popup.
I found this great article which immediately solved my problem : http://www.hardcodet.net/2009/09/activating-wpf-popups-ensures-controls-are-enabled
The root cause of my issue is that a Popup’s HWND has the WS_EX_NOACTIVATE flag set, meaning that the focus is not set properly.
Credit to Philipp Sumi and Andrew Smith.
For a while now we’ve been using a very simple pattern for opening custom popups by binding to the IsChecked property of a ToggleButton. It’s simple, needs no code-behind, and works 99% of the time.
However, it has a very annoying 1% which is the following:
- You want your popup to open when the toggle button is clicked – OK
- You want your popup to close when the user clicks elsewhere – off the window, etc – OK
- You want your popup to close when you click the toggle button again- BUT THIS DOESN’T WORK
The reason is because the events happen as follows:
- Open the Popup by clicking on the Toggle Button
- Click on the Toggle button again
- Before the “Click” is processed by the toggle button, the Popup handles the fact that the user has clicked elsewhere and so closes
- By closing, the popup sets the IsChecked state of the toggle button back to unchecked via the 2-way binding
- Now the “Click” is handled by the toggle button, but at this point the popup is closed, and the toggle button is not checked, so it re-checks itself, and re-opens the Popup !
Many people have tried to solve this by using Timers, behaviours, fiddling with the Binding, but there is an annoyingly simple solution:
On the ToggleButton set the Property ClickMode=”Press”
…and you’re done…
Filed under UI Hints, UX, WPF
I just came across an interesting use case which I thought I’d share – why let your application churn away doing unnecessary processing if the user isn’t paying attention?
So I started looking into detecting whether the workstation is locked, or if the screensaver is running – two fairly reliable ways of telling that the user has gone walkabout…
To detect a locked workstation, you need to listen out for:
…which fires each time the user locks or unlocks the workstation.
To detect the state of the screensaver, you have to do slightly more work – there are no helpful events – instead you need some sort of polling mechanism to call away to a Win32 function:
private const int SPI_GETSCREENSAVERRUNNING = 0x0072;
static extern bool SystemParametersInfo(int action, int param, ref int retval, int updini);
int active = 1;
SystemParametersInfo(SPI_GETSCREENSAVERRUNNING, 0, ref active, 0);
bool screenSaverActive = (active == 1);
So I stitched these 2 bits of logic together into a nice helper class and now I can tell (within reason) when my users are there or not, and give our servers a break every now and then.
It’s been a while since a last posted, but as with any new love there’s always an intense honeymoon period when you can’t keep your hands off! In my case, it’s WPF – a new toy that is ticking all the right boxes for a GUI nut like me.
The initial buzz soon wore off when I realised that you shouldn’t really try to write WPF apps like you did with Winforms – and then the real fun started as I rapidly scaled the learning curves of styling, databinding, MVVM and MEF.
One resource that really helped switch my brain over from old-school winforms was a video by Jason Dollinger over at Lab49 : http://www.lab49.com/2011/12/06/model-view-viewmodel-tutorial/
The video starts with a “badly written” WPF app (i.e. WPF written as if it was winforms) and then, over the course of 90 minutes, Jason gently refactors it towards a slick, high-performance MVVM implementation.
Filed under C#, UI Hints, WPF