Idle time using DispatcherTimer - Not Working - wpf

I have an application all done in WPF, using MvvM/Prism/Unity and Remote as datasource.
I need a basic thing that on win forms is really easy, just check if the app is iddle after few minutes , and if is idle, lock the app and show the login screen.
After some search on google I ´ve found one solution that uses DllImport and another using pure Wpf methods.
I don´t know I , after I implemented the Wpf way (pls check the code below) it only works after I login into the app , if I open and click in a simple texbox or hit a search, the idle method is not fired, looks like there is something hanged in the background that makes Wpf idle routine to think that it´s doing something when it´s not.
How can I check all the services/methods/etc.. that are in memory related to may app ? callstack doesn´t show to much for me. I am affraid that or I am not calling in the correct way the remote services or I implemented something wrong on the props PropChanged events/observablecollections/etc...
Is there a better way to do this using 100% Wpf structure ?
private void CheckIdleTime()
{
handler = delegate
{
DispatcherTimer timer = new DispatcherTimer();
timer.Interval = TimeSpan.FromSeconds(5);
timer.Tick += delegate
{
if (timer != null)
{
timer.Stop();
timer = null;
System.Windows.Interop.ComponentDispatcher.ThreadIdle -= handler;
Console.WriteLine("IDLE! Lets logoff!");
this.LockApplication();
Console.WriteLine("logoff fired");
System.Windows.Interop.ComponentDispatcher.ThreadIdle += handler;
}
};
timer.Start();
Dispatcher.CurrentDispatcher.Hooks.OperationPosted += delegate
{
if (timer != null)
{
timer.Stop();
timer = null;
}
};
};
ComponentDispatcher.ThreadIdle += handler;
}

There will be default window events find the idle time... i think it will be wise if we use same events for wpf or any other applications...
following link will help you to implement it..
Application.Idle event not firing in WPF application

Related

Waiting for XAML layout to complete

I am making some changes to a page (by adding/removing controls) and I want to continue with my code only when the layout is settled (all elements measured and arranged etc).
How do I do this? Is there some Task I can await on that will fire when layout is complete?
(Right now using Yields and other tricks, but they all make me feel dirty)
You can build a Task around any event by using TaskCompletionSource<T>.
In your case, it sounds like UIElement.LayoutUpdated may be the event you want (not entirely sure about that - WPF layout details are not my strong point).
Here's an example:
public static Task LayoutUpdatedAsync(this UIElement element)
{
var tcs = new TaskCompletionSource<object>();
EventHandler handler = (s, e) =>
{
element.LayoutUpdated -= handler;
tcs.SetCompleted(null);
};
element.LayoutUpdated += handler;
return tcs.Task;
}
Then you can use this method to await the next instance of that event:
await myUiElement.LayoutUpdatedAsync();

Song class not working properly

In my silverlight WP7 app, I am using XNA library to play sound. Following is the code.
Microsoft.Xna.Framework.Media.Song s = Microsoft.Xna.Framework.Media.Song.FromUri("song", new Uri("bmusic.mp3", UriKind.Relative));
Microsoft.Xna.Framework.FrameworkDispatcher.Update();
Microsoft.Xna.Framework.Media.MediaPlayer.IsRepeating = true;
Microsoft.Xna.Framework.Media.MediaPlayer.Play(s);
It starts playing the sound and stops after a second, while the song is 10 secs long. What is wrong ?
Silverlight is event based, whereas XNA is more loop based. You need to enable XNA framework events, as explained here. As a quick test to see if that is the issue, in your page's constructor, you can add this:
DispatcherTimer timer = new DispatcherTimer();
timer.Interval = TimeSpan.FromMilliseconds(30);
timer.Tick += delegate { try { FrameworkDispatcher.Update(); } catch { } };
timer.Start();

MessageBox.Show early in App startup causes app to terminate

As part of my App's startup procedure, it checks data integrity, and if it finds a problem it pops up a message to the user telling them that it might take a while to repair things.
I'm showing the message using MessageBox.Show. Because the data check is done from a worker thread, I'm switching over to the UI thread to make that call, and then setting a ManualResetEvent to tell the worker thread when the user has acknowledged the message.
I kick off the data check/load very early in the app's lifecycle from the constructor in the main Application class, by spinning off a worker thread (using the ThreadPool).
When I run with the debugger, and the message is displayed, the app just waits for input. When I run without the debugger, the app terminates after displaying the dialog for 10 seconds.
That 10 seconds is a big clue - it tells me that the OS thinks the app took too long to initialize (the OS kills apps that take too long to start up).
I think that my MessageBox.Show is blocking the UI thread before the App.RootFrameNavigating has a chance to be invoked.
My questions:
Does my diagnosis sound right?
I'd prefer to kick off my data load early, because it is almost entirely IO, except for this Message Box, and the sooner I can get my Model loaded, the better, but do you normally delay your data load until later in the app lifecycle?
Any other ideas/suggestions? I can't guarantee which page will be the start page, because the app could be resuming to any page. I'm also thinking of having the MessageBox.Show delay itself until the app has initialized, perhaps polling away for a flag set by App.RootFrameNavigating - does that make sense?
I think your problem is a result of kicking off the worker thread in the Application constructor. You should use the appropriate life-cycle event, in this case: PhoneApplicationService.Activated Event
So, the solution I've come up with is to still kick off the data load in a worker-thread from the Application's constructor, but in my PhoneService's class ShowDialog method that I invoke to invoke MessageBox.Show, I check to see if the initial navigation has occurred:
private readonly ManualResetEvent _appInitialized = new ManualResetEvent(false);
public void AppInitialized()
{
_appInitialized.Set();
}
public void ShowDialog(string caption, string text, Action<MessageBoxResult> callback, MessageBoxButton button = MessageBoxButton.OKCancel)
{
_appInitialized.WaitOne();
DispatcherHelper.CheckBeginInvokeOnUI(() =>
{
var result = MessageBox.Show(text, caption, button);
if (callback != null)
{
callback(result);
}
});
}
Then in my Application class:
private bool _firstNavigate = true;
private void RootFrameNavigating(object sender, NavigatingCancelEventArgs e)
{
if (_firstNavigate)
{
_firstNavigate = false;
var navigationService = (NavigationService) sender;
navigationService.Navigated += NavigationServiceNavigated;
}
....
private void NavigationServiceNavigated(object sender, NavigationEventArgs e)
{
var navigationService = (NavigationService)sender;
navigationService.Navigated -= NavigationServiceNavigated;
PhoneServices.Current.AppInitialized();
}
Anyone see any issues with this approach? Anyone come up with a better way?

How can I avoid Thread.Sleep when using the WPF Automation Framework?

I am trying to use WPF UI Automation working without using spurious thread.sleep statements. What I would like to do is have a function GetElementById that continually polls until the control is available (or a timeout occurs). The problem is that it appears to cache the child controls of my parent element. Is it possible to refresh to Children? Or does anyone have an alternative approach?
public AutomationElement GetElementById(string id, int timeout)
{
if (timeout <= 1000) throw new ArgumentException("Timeout must be greater than 1000", "timeout");
AutomationElement element = null;
int timer = 0;
const int delay = 100;
do
{
element = MainWindow.FindFirst(TreeScope.Descendants, new PropertyCondition(AutomationElement.AutomationIdProperty, id));
Thread.Sleep(delay);
timer += delay;
} while (element == null && timer < timeout);
if (element == null) throw new InvalidOperationException("Unable to find element with id: " + id);
return element;
}
If there is a better way than judicious use of Thread.Sleep, I've yet to find it.
UIAutomation does provide Events, and I guess that you could (to use your case as an example) listen for the event that occurs when the TabItem is selected, and only then continue to find the item by Id. But I suspect that this kind of pattern would play havoc with the overall readability of your code.
The DoEvents function that is available in System.Windows.Forms.Application namespace is used to enable the UI to update while a long running process is occuring. It is not a member of the WPF namespaces. You can use something sililar by implementing it yourself as in this article or importing the System.Windows.Forms namespace and calling Application.DoEvents. This will allow your other processing to continue while you are doing your polling. It is a function to be used with caution.

How can I force my busy indicator to display? (WPF)

I've created a busy indicator - basically an animation of a logo spinning. I've added it to a login window and bound the Visibility property to my viewmodel's BusyIndicatorVisibility property.
When I click login, I want the spinner to appear whilst the login happens (it calls a web service to determine whether the login credentials are correct). However, when I set the visibility to visible, then continue with the login, the spinner doesn't appear until the login is complete. In Winforms old fashioned coding I would have added an Application.DoEvents. How can I make the spinner appear in WPF in an MVVM application?
The code is:
private bool Login()
{
BusyIndicatorVisibility = Visibility.Visible;
var result = false;
var status = GetConnectionGenerator().Connect(_model);
if (status == ConnectionStatus.Successful)
{
result = true;
}
else if (status == ConnectionStatus.LoginFailure)
{
ShowError("Login Failed");
Password = "";
}
else
{
ShowError("Unknown User");
}
BusyIndicatorVisibility = Visibility.Collapsed;
return result;
}
You have to make your login async. You can use the BackgroundWorker to do this. Something like:
BusyIndicatorVisibility = Visibility.Visible;
// Disable here also your UI to not allow the user to do things that are not allowed during login-validation
BackgroundWorker bgWorker = new BackgroundWorker() ;
bgWorker.DoWork += (s, e) => {
e.Result=Login(); // Do the login. As an example, I return the login-validation-result over e.Result.
};
bgWorker.RunWorkerCompleted += (s, e) => {
BusyIndicatorVisibility = Visibility.Collapsed;
// Enable here the UI
// You can get the login-result via the e.Result. Make sure to check also the e.Error for errors that happended during the login-operation
};
bgWorker.RunWorkerAsync();
Only for completness: There is the possibility to give the UI the time to refresh before the login takes place. This is done over the dispatcher. However this is a hack and IMO never should be used. But if you're interested in this, you can search StackOverflow for wpf doevents.
You can try to run busy indicar in a separate thread as this article explains: Creating a Busy Indicator in a separate thread in WPF
Or try running the new BusyIndicator from the Extended WPF Toolkit
But I'm pretty sure that you will be out of luck if you don't place the logic in the background thread.
Does your login code run on the UI thread? That might block databinding updates.

Resources