Maybe I'm mis-remembering how Winforms works or I'm overcomplicating the hell out of this, but here's my problem.
I have a WPF client app application that talks to a server over WCF. The current user may "log out" of the WPF client, which closes all open screens, leaves only the navigation pane, and minimizes the program window. When the user re-maximizes the program window, they are prompted to log in. Simple.
But sometimes things happen on background threads - like every 5 minutes the client tries to make a WCF calls that refreshes some cached data. And what if the user is logged out when this 5 minute timer triggers? Well, then the user should be prompted to log back in...and this must of course happen on the UI thread.
private static ISecurityContext securityContext;
public static ISecurityContext SecurityContext
{
get
{
if (securityContext == null)
{
// Login method shows a window and prompts the user to log in
Application.Current.Dispatcher.Invoke((Action)Login);
}
return securityContext;
}
}
private static void Login()
{
if (securityContext == null) { \
/* show login window and set securityContext */
var w = new LoginWindow();
w.ShowDialog();
securityContext = w.GetSecurityContext();
}
}
So far so good, right? But what happens when multiple threads hit this spot of code?
Well, my first intuition was that since I'm syncrhonizing across the Application.Current.Dispatcher, I should be fine, and whichever thread hit first would be responsible for showing the login form and getting the user logged in...
Not the case...
Thread 1 will hit the code and call ShowDialog on the login form
Thread 2 will also hit the code and will call Login as soon as Thread 1 has called ShowDialog, since calling ShowDialog unblocked Thread 1 (I believe because of the way the WPF message pump works)
...the end effect being that I have multiple login forms popped up to the user at once.
All I want is a synchronized way of getting the user logged back into the application...what am I missing here?
Thanks in advance.