I have a background process running on the user’s macOS machine. Its job is to detect whenever any app is launched on the machine. Currently, I am detecting the NSNotificationCenter’s NSWorkspaceDidLaunchApplicationNotification event. This works perfectly for detecting when an app is freshly launched (i.e. the app had no instance already running at that time).
But, on macOS, if we click the red cross button at the top-left corner, it generally closes the app window and the app continues to run in the background. This is also evident by the app icon visible on the dock with the dot indicator below it. If I click the app icon on the dock and then launch it, the NSWorkspaceDidLaunchApplicationNotification event won’t be triggered.
To track such events, I tried using the NSWorkspaceDidActivateApplicationNotification event. Using this event, I was able to detect all the app launch scenarios. The problem is that this event gets triggered whenever the app comes into focus such as switching windows using command+tab, clicking on its dock icon, changing between two apps, …
Is there a way to filter out these triggers or identify which action led to the trigger? Or is there some other event/ method I can listen to which gives the required filtered triggers? I only want to detect scenarios where a new window of the app is created.
What you seems to want is two different things, as was mentioned in comments, which should be processed separately to be reached.
To detect app launch, when the new process is started. You could use the NSWorkspaceDidLaunchApplicationNotification if it is enough (usually for visual user apps), or kqueue if it is not, or even EndpointSecurity framework to rule them all.
To track the window(s) in the already launched app. Visually, if the white dot under app dock icon is there, the app is still launched.
There is an Accessibility framework for this task, you could track the event of window creation, window destruction, get count of windows from target process id, visibility state and etc.
It is a bit abandoned and has no updates since maybe release, but it will work for you in most cases.
Related
I have created Mobile application in React native.
My problem is that whenever i open my app from launcher icon and minimize for sometime (eg: 10 minutes) then if i re-open my application from recent apps or else on clicking launcher icon again it should restart the application as it opening for the first time.
But doesn't matter how much time i minimize the application when i open it again it will open as a previous state.
How to solve this issue.
What Navigation module are you using? Depending on it, you need to call a method to init the app and that method must be called again when you switch back to the app.
Normally, application has their inherent state as snapshot when it go to background if the user do not close directly.
If you are testing on android, pressing backbutton on top of the navigation makes close the application. (you can control this if you want.)
In iOS, pressing home button always send the application into background instead of close.
I am not sure what OS you are using for development. But refer it.
I have a Winforms app with a main form where a multiline text box is updated during a long running process.
I would like to be able to use the ALT-TAB facility of Windows to switch away from the Visual Studio 2012 IDE to watch the form being updated as the app runs.
Is there some option that controls this? If I have other apps running such as Notepad I can toggle away from the IDE but navigating in this way to the running Winforms app seems to be disabled.
Last time I debugged an app like this I recall this sort of switching worked but sometimes there was a lag in the rendering of the screen.
The winforms app is not multithreaded.
Any ideas?
The winforms app is not multithreaded.
Which means you're doing all your lengthy processing on the UI thread. And that, in turn, means that during that processing, your app is ignoring all the messages Windows is sending it, like the "hey, somebody just Alt+Tabbed to you, so bring yourself to the front" message.
You either need to sprinkle your code with frequent calls to Application.DoEvents (not recommended, but could work if you don't intend to maintain this app long-term), or move your long-running logic into a background thread so your UI thread can stay responsive to messages.
I have written a WinForms driver safety application for a windows tablet device that will blank the screen (display a full screen blank topmost window) when it detects that the car is moving at say more that 15km/h (using the tablets GPS).
The software has worked fine under Windows 7 but I'm struggling a bit to get it working under Windows 8. My first challenge is to display the blank screen when the Metro start menu is currently displayed. So if the user has the Metro start menu displayed and the car starts moving > 15 km/h my blank screen should display... I need to steal the focus from the metro interface and display my blank window on the desktop.
To test this I wrote a simple vb.net app in 2010. It had a form with a timer firing every 3 seconds. In the Tick event I had the code:
Beep()
Me.Activate()
When I ran this with the debugger and pressed the windows key to show the Metro Start Menu, it worked... The focus switched back to the desktop (and my window). However, when I ran this without the debugger and did the same thing I could hear the beeps but the focus never switched back to the desktop.
Any ideas why the behaviour would be different? Any ideas on how I replicate the same behaviour I get when the debugger is attached?
I have tried a few things like AppActivate, setting the form TopMost, BringToFront but unfortunately this hasn't worked.
The only half solution I have come up with is to send a windows button keystroke but this has other issues.
Windows specifically tries to prevent applications from stealing the foreground from other apps. See the SetForegroundWindow documentation for commentary on this and the factors that can let an application come to the foreground (all of the methods you are trying essentially come down to a SetForegroundWindow call).
Note that one of the explicit blocking circumstances is "The foreground process is not a Modern Application or the Start Screen."
This works for you when debugging because "The process is being debugged" is one of the cases which explicitly allows foreground privileges.
Because this is a generally user-unfriendly thing to do there isn't a good general purpose way to bypass this behaviour and steal the foreground.
Likewise, normal apps cannot run on top of Modern applications or the start screen.
You may be better off locking the system by calling the LockWorkStation function.
How can I prevent other windows within my application from receiving focus? I want to bring a loading window to the front and let it do its thing, but I don't want the user to be able to interact with the other windows in the app.
I could simply hide the other windows in the app, but that feels kind of jarring for users to have their windows just suddenly disappear. At the same time, I can't let the user continue interacting with the other windows during a load since the load will be updating data on every window (synchronization problems would occur). I can add additional locking mechanisms, but I'd rather not if it is as simple as forcing a single window to stay on top and remain in focus.
Thanks!
Look into modal windows.
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/WinPanel/Concepts/UsingModalWindows.html
You can make a whole window or panel run in application-modal fashion,
using the application’s normal event loop machinery but restricting
input to the modal window or panel. Modal operation is useful for
windows and panels that require the user’s attention before an action
can proceed. Examples include error messages and warnings, as well as
operations that require input, such as open dialogs, or dialogs that
apply to multiple windows.
VS2012's default C# "Metro style" project templates include code in App.xaml.cs (in the OnLaunched override) to restore the application state after a suspend-and-terminate. This code only runs when LaunchActivatedEventArgs.PreviousExecutionState is Terminated, i.e., "The app was terminated after being suspended."
How can I force my app to be suspended and terminated, so I can test this suspend/resume functionality in my app?
Things I've tried that don't work:
If I use the "close app" gesture (drag from the top of the screen to the bottom), then the next run's PreviousExecutionState is ClosedByUser.
If I kill the app -- either using Task Manager, or (if I was debugging) with the "stop" button on the VS toolbar -- then the next run's PreviousExecutionState is NotRunning. This is true even if Task Manager showed the app as "Suspended" before I ended task, so clearly it's more nuanced than the description of "terminated after being suspended".
You'd think I could just switch away from my app, and then open lots of other Metro-style apps until my app eventually gets kicked out. But even if I open every single Metro-style app that ships with the Windows 8 Release Preview, that's apparently not enough memory pressure to make Windows terminate my app. (I assume Windows would be less likely to terminate an app that was being debugged, so I launched my app from the Start screen -- no debugger -- before I tried this.)
It does appear that, if I switch away from my app and type into a StackOverflow window for several minutes, that my app will eventually get terminated, so perhaps there's a time-based component to it. But if I have to wait five or ten minutes every time for my app to terminate, that's a pretty slow testing cycle.
Given that this is something developers will have to test, you'd think there would be a nice, easy way for a dev to force an app to suspend-and-terminate. Is there some kind of stress-test app that comes with Visual Studio that will force enough memory pressure? Is there some menu item in Visual Studio that will force termination of my app? How are we supposed to test this?
In Visual Studio 2012, when you're debugging, there are "Suspend", "Resume" and "Suspend and Shutdown" buttons. By default, you should see the buttons while you are debugging your app. See this article for more info on debugging process lifecycle.
I had trouble finding the Suspend control because VS wasn't showing a second row of toolbars for me. As it turns out, this is on the "Debug Location" toolbar. Make sure you have this toolbar turned on and then you should be able to find the Suspend control (and it does work to solve the OP's problem).
If they don't show by default, go to TOOLS -> CUSTOMIZE, and under the Toolbars tab, check the box that says "Debug Location"
I was looking for VS 2013, just in case others came for the same reason.
Source:
http://blogs.msdn.com/b/visualstudio/archive/2012/08/23/new-visual-studio-2012-debugging-features-for-the-windows-8-app-lifecycle-model.aspx
a busy cat http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-01-29-92-metablogapi/2210.image_5F00_thumb_5F00_1FBA9C1E.png