App close event without resritcted Capability - c#

I have developed an app for the Microsoft store. The problem is, that I can not upload this app to the store, because I've used the confirmAppClose capability, to detect when my app gets closed.
Does anybody know another way to detect when my app gets closed?

Does anybody know another way to detect when my app gets closed?
I am afraid there is no way to detect or prevent the app from exiting without using the confirmAppClose restricted capability. That's why it was introduced in the first place.
When it comes to store submission, you'll need to provide additional information on the Submission options page in order to receive approval for an app that uses a restricted capability.

Related

UWP to launch my application from WPF application

I have a Windows store app I want to run (if not running) or expand (if not expanded) of another of my app written in WPF.
Through The Process.Start() I could not do. Tell me, can this be done? Thanks for the help!
To launch an UWP app from another app, you could make use of deep linking.
Here is a great article describing exactly how to do that
In summary, you need to add a protocol declaration (essentially a URL with a custom scheme), handle the activation event and then you can launch that app by navigating to that URL from your other application.

Mobile app exit confirmation

What I need is to provide an exit confirmation dialog for my mobile app.
The dialog is to appear when users taps the Back button on their phones. I know two options i.e.
"Press back again if you really wish to exit" type of message.
"Do you really wish to exit + Yes/No" dialog.
I am exploring the second variant.
The problem I see primarily concerns the windows store apps.
If I show it and give user time to decide than I have already cancelled the default behavior.
For windows store app it is Windows.Phone.UI.Input.HardwareButtons.BackPressed i.e. I've set the Windows.Phone.UI.Input.BackPressedEventArgs.Handled to true.
What do I do if user clicks Yes i.e. confirms his intent to exit the app?
I've read the Metro App can no longer be programmatically killed and do understand that programmatically closing the windows store app is considered "unacceptable". Does it mean that such an exit confirmation dialog is banned for windows platform?
What about Android? Is it ok there to exit the app programmatically?
Formally Windows Store Policy does not allow such behavior:
Where applicable, pressing the back button should take the user to a previous page/dialog. If the user presses the back button on the first page of the app, then the app terminates (unless it is allowed to run in the background).
So you might be lucky to pass certification, but it is definitely not recommended behavior.
For "testing purposes" there are two methods exposed in API to programmatically exit application:
High-level Application.Current.Exit()
Low-level CoreApplication.Exit()
Technically you can use one of these methods to force application to close after user confirmed to exit. But there is no guarantee that you will pass certification.
For Android there are also guidelines. In particular the Core App Quality guide says that
App does not crash, force close, freeze, or otherwise function abnormally on any targeted device.
There are various discussion on Stack Overflow on how to correctly close Android app (example).
From my experience such apps do path certification, but Play team may choose to not promote them as they don't follow official design guidelines.
You could by using the onBackPressed callback method and showing a dialog, but as Jason said, it is a bad practice on Android too.
Let me explain why.
The OS has a PackageManager which manages every apps on the device. Apps have a priority level. That's why the phone app opens when it receives a call and yours get paused (in background). If the active app with the highest priority level needs memory or if your device encounter any problems, it can destroy your activities and then close your app automatically.

Can I remap the button on my headphones to control the pandora app on windows?

I would like to write a program that can intercept the windows message that is sent when I press the button on my apple headphones and remap that to send a message to my desktop pandora app to play/pause. Is there already a utility that accomplishes this? Does the .NET framework give me access to these messages? Would I be able to access the message before it is sent to it's default program?
Is there already a utility that accomplishes this?
No clue. Probably not. SO isn't for recommendation questions anyways.
Does the .NET framework give me access to these messages?
No. Not easily anyways.
Would I be able to access the message before it is sent to it's
default program?
I don't know about timing, but you should be able to access it. You'll need to set up a hook (MSDN). Unfortunately, this is in the Windows API and so you'll need to use PInvoke to actually call the native (C++) methods needed.

A service that would track and catch whenever someone is trying to take a screenshot

Is it possible to write a service program that would catch an event of someone trying to take a screen capture? Not that of pressing a printscreen button or any other key combination, though, but of the event itself, even if it is done by some external tool?
You can't realistically, because anyone could write a simple application that can take a screenshot.
The command being, GetDC(NULL) (msdn GetDC).
Hooking this function also wouldn't work since apps can make use of this for legitimate reasons so you'd have to try and filter out false positives.
Also, you've only prevented one class of problem, what if the user emails the file to someone? What if the user copies the text rather than uses a screen shot? What if the user takes a photo using their mobile phone?
If you have sensitive information that must be protected the only real option is to educate users and/or restrict their access. E.g. machines with sensitive information are not connected to a public network, USB drives are disabled and user's are not allowed to bring anything with a camera or data storage near the machines.
If it's just to avoid silly mistakes, then you could hook the keyboard and look for the print screen key. This however will not detect applications (such as Snipping Tool).
This could be done via a clentscript and using AJAX to send a message back to your servers, however you cannot guarantee the user wont have javascript turned off, or the user gets around this by running through a proxy or vm environment.
In short you could do this but there is no way to 100% guarantee its effectiveness.

How to give an Exceed X-window focus in a C# application?

Currently our software is running on AIX Unix machines, but we use Windows boxes running Exceed to display the UI in X-windows. I'm writing a Windows application ( modernizing the UI in C# ), but some of the legacy windows still need to be displayed in Exceed. When a user clicks a button on my windows application, it sends a message to the Unix server which displays the X-window. My problem is that these X-windows are not getting focus, so they are popping up BEHIND all of my .NET windows/forms.
A user of this software can easily have 5+ windows forms open at any given time, so it is a big inconvenience if every time they want to display a legacy X-window, they have to minimise all of the .NET windows. What is the best way for me to solve this? Is there a way for me to give Exceed focus so that it brings the X-window to the top? I tried using Application.OpenForms, but calling .SendToBack() on each form didn't help me.
If the pop-up windows are coming from a process other than the Windows app which you're creating, you'll probably need to resort to a hack. Microsoft put code into WinXP to prevent apps from being able to throw their windows in front of everything, unless it's part of the app the user is working on. To do this, you need to monkey with the ForegroundLockTimeout registry value, and the Windows APIs to pull a window to the front.
More info:
http://social.msdn.microsoft.com/forums/en-US/winforms/thread/54826e98-9faa-4457-ba1d-b645af88170b/ (The last entry contains the conclusion, but you'll need to read some of the previous entries. I also suggest you set the ForegroundLockTimeout to zero, do the switch, then set ForegroundLockTimeout back to its previous value.)

Categories