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
Related
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.
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.
When I run or debug a winrt application, Visual Studio 2012 seems to start it always on the same monitor.
How can I force Visual Studio 2012 to start the app on my other monitor?
Windows will deploy to which ever monitor you last viewed the Start screen on. So, here is what I do.
Start VS in Main Monitor
Bring up charms bar on Secondary monitor and select the Start charm
Launch debug from VS in Main Monitor
Your app should now launch in the secondary monitor.
I don't know if there is a way to set an option to do this - I haven't found one but haven't looked very hard since this works easy enough for me.
On Win8.1, it seems like the app always opens on the primary display. I swapped my primary and secondary displays (right click on desktop -> screen resolution -> "Make this my main display").
I also customized my taskbar so that it appears on all monitors (right click on task bar -> properties -> "Show taskbar on all displays").
I think, it is impossible.
The only solution you have is to move it to that monitor and then open Start Screen only on it while debugging.
In this case Win Store apps will open there
You cannot force the app to start on the second monitor but you can move Visual Studio 2012 to the second monitor and start the WinRT app on the first monitor. Swap or move the primary monitor if needed.
You do just active the Metro screen where you want to start the app ! Or after you can use these shortcut : Win+PageUp and Win+PageDown to switch
You can also drag the app itself to the alternative monitor. As others have noted, the apps will continue to open on the last monitor that you used.
Update: If you have Visual Studio 2013, the latest update remembers which monitor was being used to run the WinRT app and opens it on that screen.
I'm writing a simple Cocoa Application, no core data or multiple document support. Running on a Mac Pro, OS X 10.6.6, Xcode 3.2.3.
I have reduced my application to the following code in my AppDelegate class:
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
NSOpenPanel *openPanel = [NSOpenPanel openPanel];
[openPanel runModal];
return;
}
From within the debugger, I will run my application. As expected a somewhat not-to-useful OpenPanel will appear. I will click Cancel and it will disappear. All this is as expected. When I click [Command + Q] to Quit the application, the UI will go away but the debugger will indicate that the application is still running (as does the console output).
Based upon all the information I'm reading, I should not have to do anything else in order for this to run right. I've downloaded several examples on the Open Panel's usage but most use the deprecated methods of opening modal giving additional information as parameters. FWIW, I tried those methods and am still seeing the same result.
One last item, when the Open dialog appears, just for an instant I see a message box asking me something to the extent if I want my application to receive incoming connections. The dialog quickly disappears. I don't know if that is part of my problem or not. [Update - this deals with my Firewall being turned on.]
Yes, I'm fairly new at Objective C but not at programming in general. Any words of wisdom is greatly appreciated!
2011.02.07 - Update:
I have walked the debugger line by line without incident. There is no indication of any program failure in the console window.
I say that the debugger is still active after [Command + Q] because the Stop Process toolbar button is still enabled as is the Break button. Further the console indicates that after I tell the application to terminate (either via the menu or key command) that it is still running. The following is the Complete console output from start of run to after I Quit the application.
Program loaded.
run
[Switching to process 62370]
Running...
The Activity Monitor (system tool) will show my application terminating (no longer shows up as a process) but the Debugger will still not transition to "edit" mode - if I tell Xcode to run the debugger again, it will ask me if it's OK to Stop the current debugging session. If I was in Windows I would start looking for background threads keeping the process alive but as far as I know, NSOpenPanel should not be doing something like that.
I have further simplified the program to nothing more than creating a brand new Cocoa application and inserting the code snippet above - no other additions to the template project or updates in any way.
And lastly, when the application is run under the Leaks Performance Tool, everything runs fine when the panel is created but never used. When created and actually used though, at the end of the run I will get the following message in the tool "insufficient task_for_pid privileges (leakagent64)". Googling this hurts. If I read it right, the debugger does not have sufficient permissions to fully kill the target process ??? Now that sounds stupid but ... It does not make sense!
Another update - I just downloaded and ran FunHouse, one of the SDK sample applications that also uses NSOpenPanel. Well don't I feel special. It exhibits the same exact behavior. So from this I conclude either Apple has a bug in their code, my machine is special and messed up, and finally, it is Not my code that is at fault. That being the best part. Tomorrow, I will use a friends Mac and see if the same behavior is exhibited on his box.
This is just too weird.
I rebooted my box, took it to work and found it worked like a charm! I will assume this is fixed and has nothing to do with any other connected devices at home as compared to at work.
If it re-exhibits at home, then it is a network/device issue. Thanks all for your inputs and suggestions! Very much appreciated.
What, specifically, does the debugger say? It's possible that your program crashed, so the debugger is showing you information about the crash.
What if you omit any attempt to run an Open panel?