I am developing an windows runtime app for phone.
I just wondering why my app is killed after I clicked windows button? According to msdn it says app will just be suspended, what implementation do I need to keep is suspended and when user click on back button on hardware, it will stay there.
Related
ISSUE:
On a touch panel with no keyboard, my QT C++/QML app running on Windows 10 IOT has the fullscreen GUI "frozen", when the monitor turns on (after the user has triggered the touchscreen), after it has timed-out earlier and turned off due to power settings. Mouse cursor still updates.
The QML GUI has "flags: Qt.FramelessWindowHint | Qt.Window"; I do not want to add "Qt.WindowStaysOnTopHint" as it will block the control panel window when it is open from the app. The program is verified to be still running, only the GUI has frozen from the point in time when the screen turned off.
TEMPORARY RESOLUTION:
The only way to "unfreeze" the fullscreen GUI is to connect a keyboard & press the Windows key to show-hide the start menu, or do it programmatically with a manual QML button placed at a known position or on detection of monitor WM_POWERBROADCAST messages.
When the app is not fullscreen, the freezing doesn't seem to be happening.
Is this due to some missing WM_MESSAGES (e.g. WM_PAINT, WM_ACTIVATE, etc) sent by the OS to the app when it is fullscreen, or when the start menu button is pressed?
Can the app-fullscreen-freezing on monitor-turn-back-on be rectified by the app programmatically sending a sequence of WM_MESSAGES to itself, but not the Win button keypress (as the normal user is not supposed to access the OS or see anything related to the OS when the app is running)?
I tried using winAPI SetForegroundWindow() function...?
:-( Fast forward a few days...
With further testing, it seems that using SetForegroundWindow() alone is not consistent/reliable. Sometimes it works, sometimes it doesn't.
The most reliable that works 99.999% of the time is still the VK_LWIN keypress sent by the app. But, as mentioned before, the app user is not supposed to see the start-menu appearing then disappearing. Best if the behavior of the VK_LWIN keypress could be duplicated to the app without seeing the start-menu...
I got a requirement to show a toast notification from a desktop application, i follow the instruction from the link:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh802768%28v=vs.85%29.aspx
According to this instruction, i must create a shortcut to my app, with a System.AppUserModel.ID,but the problem is, the shortcut will display under "all apps" screen in win8, but i dont want the shortcut shown there, so is there anyway to avoid creating the shortcut, or hide the shortcut. Thansk!
OS: Win8
I have a question about the expected behavior of Window Phone 7.5 emulator.
If I deactivate (start button), close (back button from first screen) or tombstone my data (selecting this option in VS first and then in the emulator clicking start button), and then press Stop Debugging (Shift+F5) in VS, all changed data in my app for that session is retained when I start the debug process again (F5).
However, when I just changed data in my app in the emulator and don't actively deactivate, close or tombstone my app, and then press Stop Debugging (Shift+F5) and then Start Debugging (F5) the changed data is not retained. I've noticed that upon stopping debugging, neither the Application_Deactivated or Application_Closing occur as well.
Is this expected behavior when starting/stopping the debugging processes? I'm asking because I need to know if this has any effect in the real world, like for example if I'm in my app and make a change and then someone turns off the phone completely right then and there and turns it back on, will my data be retained
This is expected. What you are doing is effectively crashing your app. If the phone/app is shut down in a normal situation then Deactivated or Closing will be invoked.
I have a windows phone 7 app that uses GPS to track user position. Now the user can disable this feature through the phone's setting menu. the app handles this disabling fine and gives them a message. This is all pretty standard windows phone stuff.
My question is whether I can navigate (inside the app) to the settings menu so that the user can enable phone location services? Ideally I would give them a link or a button that they touch and they are then taken out of the app to the settings menu. They would then click 'back' and return to the app.
No, at the moment, there's no way to fire up the Settings menu from inside your app.
Try this:
Windows.System.Launcher.LaunchUriAsync(new Uri(“ms-settings-location:”));
Not sure if it works on WP7 though.
http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj662937(v=vs.105).aspx
I have a WP7 application that I've disabled the idle capabilities of the phone with such as:
PhoneApplicationService.Current.UserIdleDetectionMode = IdleDetectionMode.Disabled;
PhoneApplicationService.Current.ApplicationIdleDetectionMode =
IdleDetectionMode.Disabled;
However, the camera button and start menu still pause the application and resume it afterwards. I want the app to run regardless of these buttons being pushed. How can I prevent these buttons from tombstoning the app?
Tombstoning always occurs if the user presses the windows key or camera button. The code you've shown ensures that your app will continue to run under a lock screen, not if it will run when your app is tombstoned. In the current version (7.0), there is no multitasking for third parties, whereas Mango (7.1) allows for some more freedom with respect to multitasking.
Presumably this app is targetted at 7.0, so your app will be tombstoned and you will have to handle it. There is no way of having your app continue running in the background.
On a side note, you'll still have to handle tombstoning in Mango as well, but you do get more abilities to run your app in the background.