How can you tell when a windows 8 Metro app gets put in the background? The suspended state doesn't activate. I have a break point on. It only hits if I close the app.
I am using a webcam and since no apps can run in the background I need to save my work when it's put in the background.
The windows phone it was application deactivated.
any help would be nice.
Apps do not normally get suspended when in the debugger. However, you can force a suspend when debugging by:
Enabling the Debug Location toolbar (red arrow in image below).
Then press the Suspend button (blue arrow).
The suspending event should fire when the application is no longer active, namely, when another application is brought to the front. Presuming you're using C#/XAML, the app.xaml.cs file already has the Suspending event wired up. In HTML5/JavaScript it's checkpoint and you'll see it in default.js.
Related
I am developing a WPF application when the application is shown a thread work
and show a refreshed data on the application ui .
for saving performances i want to stop this Thread if the application is 100% covered by another application .
for example if the user is using another application that take the right half of the screen ,and my app is shown on the left half of the screen , the app must steel works cause the user is using the other app and watching the
changed data on my app .
if the application is back grounded or 100% covered by another app window or
minimized must stops;
i tried many solution like using the Deactivation event of the window
and p invoke but that not resolve the situation.
and thanks you.
My WP 8.1 store app behaves very strangely. App Resuming event fires as expected when I quickly navigate away and then come back. But If I keep the app in background for some time and when comes back, the app fires the Constructor and OnNavigatedTo events instead of the Resuming event and has the black "Resuming..." screen for a couple of seconds(about 4 seconds).This is an app with a BackgroundAudio task. Even the sample BackgroundAudio app from MS behaves like this. Anyone knows what's wrong here?
I'm in the process of building a WP 8.1 app which uses a background audio task as well. Everything you explained happens to me also.
If you see "Resuming..." for a few seconds, then it probably means your app was terminated by the OS after being suspended first. In this case, the Resuming event won't fire because your app was completely killed and must start again. "Resuming" usually means when a suspended (not terminated) app resumes execution.
When your app is terminated and then "resumed" from the app switcher, your Application.OnLaunched() method override will be invoked with e.PreviousExecutionState == ApplicationExecutionState.Terminated. In this method, you should check if the previous execution state was Terminated, and if so, restore the app to the state it was in prior to suspension. This gives the illusion to the user that the app was never terminated and they can resume what they were doing at the time.
If you create a new Pivot App Windows Phone 8.1 project (for example), you'll see that the application lifecycle events are taken care of correctly in App.xaml.cs.
App Resuming event fires as expected when I quickly navigate away and then come back.
This is correct behavior. It takes a few seconds once the app has been backgrounded before it is suspended by the OS, so if you resume the app before the OS has suspended it, then it will simply resume from memory.
I'm not sure why background audio apps are more susceptible to termination. I even find that the Xbox Music app behaves similarly. Hopefully in the next version of Windows Phone, this issue will be addressed.
FYI here's a diagram of the application lifecycle from MSDN (I recommend you read this page for more information about the application lifecycle):
"Resuming" only occurs from the suspended to running states.
Whenever the app resumes from the background. there are two states it can be in:
Suspended: it resumes successfully, navigating directly to OnNavigatedTo; the constructor will not be called
Terminated: the app will not start from the previous state of the page you left, but instead, it will load that page anew; at this point of time you need to have saved the state while the app was suspending, so as to restore it now
Hi I'm trying to make a simple program that read keys from keyboard even if my application is running in the background.
Situation
I want make a timer to help me in a game. I already have the program with the timer, the problem is I can not start the timer without switching of the game window to my app window. So I configured the game keyboard to release the keys F11, F12. Now in game this keys do nothing.
Problem
I built a windows forms containing a listener for keydown event and a conditional for F11. But when I trigger another window (eg the game window) my application no longer hears the keyboard, cuz it's in the background.
Question
How can I build a app that hears the keyboard, even if it's not active window?
You need to install a global, low-level keyboard hook using the SetWindowHookEx API call. Using the WH_KEYBOARD_LL hook will set your application up to intercept keyboard events at all times, even when your application is not active.
This post on MSDN shows an example of how to achieve something close to what you want from C#.
How do we force an app to Suspend (NOT shutdown, just suspend) and then force-resume it ourselves when we are NOT using visual studio/debugging?
When running under Visual Studio 2012, you can enable the Debug Location on the debugger toolbar. This will allow you to select one of the three operations, "suspend", "resume", and "suspend and shutdown".
[edited]
Sorry, just noticed that you are asking for non VS solution. You can suspend your app by dragging the app down. Move your cursor to the top of the page until you see a hand. Click and hold it and pull down to suspend your app. It takes a few seconds before the app actually enter suspend mode. If you want to do things sooner, you can use visibility change to toggle certain action first, like saving critical stuff.
I'm working a small WPF based program for launching applications through system wide hotkeys implemented using hooking. I'm implementing it in C# and Visual Studio 2010.
When I detect the specific keypress I use Process.Start(...) to run the application. This works fine while Visual Studio is active, placing the new application in the foreground with input focus, as I would expect. If my launcher is in the background (behind another active program), it still detects the key and starts the application correctly, in front of everything else.
The problem is, that when I run the launcher without Visual Studio active, and my launcher application isn't front, neither will applications it starts. They appear in front of the launcher but behind the active application.
I can see that other software, like AutoHotkey, is able to do hotkey launching with this behavior, but I fail to see what I'm doing wrong.
Update: Just figured out a solution to this issue that works in my development environment. I first register a global hotkey through the Windows API RegisterHotKey using the launcher main window handle. The key could be any, but should be one that normally doesn't exist physically, F24 in my case. Then, whenever I detect a keypress through the hooks that should launch an app, I first call keybd_event to 'fake' a keypress for the hotkey.
For WPF use:
keybd_event((byte)KeyInterop.VirtualKeyFromKey(Key.F24),0,KEYEVENTF_KEYUP,0);
For WinForms use:
keybd_event((byte)Keys.F24,0,KEYEVENTF_KEYUP,0);
This will bring enough focus to the launcher, so that Process.Start(...) makes the executed program get in front. It does not bring the launcher window to front, nor does it make the launcher accept inputs.
If Activate() is called on the main window after the keybd_event(), this will bring the main window to front and allow for keyboard input, just as if the user had task switched.