What am I doing wrong here? :(
I open Instruments.app, create a new UI Recorder template, select my application's .app bundle from the Target -> Choose Target menu, hit Record, open a couple of documents, type some stuff on them, close the documents, quit the app.
At this point UI Recorder stops and the Record button changes to "Drive & Record". I hit it, I see my application get launched and Instruments start recording data. Then Instruments gets confused (somehow)... my application loses focus, and suddenly UI Recorder is replaying all of my actions in Instruments!!, which just screws with Instruments in all kinds of messy ways. In this state I'm unable to move the mouse (the system just steals the cursor back), and I'm unable to quit instruments, since when I hit CMD+Q I'm prompted to Save the document, which I can't do because I have no control of the keyboard or mouse.
This is really frustrating. Has anyone got experience with this tool who can tell me where I'm going wrong? I'm scared to run it a third time as it literally hijacks my entire system.
So, you have a memory leak, and it happens when you do a specific series of actions.
The hard way to debug this would be to just have the Allocations and/or Leaks instruments and do the actions yourself every time, and every time you screw up (leave something out, do something wrong), kill the process and start over.
The easy way is the UI Recorder.
The first time you record with it, it records your actions (at the events level, not the target-action level). Mouse movements, clicks, etc.
The way UI Recorder differs from other instruments—which is why it surprised you—is that when you record with it thereafter, it plays them back.
It's not just swinging around your mouse cursor willy nilly; it's doing what you did the first time. Every time after you do things the first time, the UI Recorder does the exact same things for you.
That's what UI Recorder is for: Perfect, mechanically-ensured reproducibility. It's doing what it's meant to do; it's working as it should.
And yeah, aborting that is hard. I haven't looked yet, but there may be a stop-recording global system hotkey you can use. There is one when Instruments is in mini mode.
Also, you can set whether UI Recorder is in “drive” (playback) or “record” mode in the little pop-over that comes up when you click on the (i) button for the instrument. Switch it to record mode to re-record your interaction for different results in future runs. (I don't know whether it preserves the recording(s) in past runs.)
Related
I have a script that I'm trying to debug, but the debugger immediately closes itself when it hits an error and dismisses the error message. I could manually open the log and wait for it to load every time I hit a stop, but that wastes a lot of time when it could just pop up on my screen. I figure it has to be an easy fix and I probably did something stupid, but one gets pretty tired of Google's shit when you've read blog headlines such as "THE 6 DEADLY SINS OF GOOGLE APPS SCRIPT ADD-ON DEVELOPMENT" for the 50th time in as many search queries. Anyways, rant over.
When I hit debug, the debugger will run, a white tray pops up at the bottom of my screen and stays empty. When it hits an error, it will flash the error message across the top of the window and immediately close/dismiss that error as well the tray that popped up. The tray looks like the one in the image below, except completely empty.
Has anyone else had this issue and know why it might be happening? Also, can anyone tell me if there is a Matlab-style workspace explorer that displays each user-defined variable and what kind of data it holds? I would find that extremely helpful in debugging. That, and a live in-window console/log.
This is a known issue. Star(on the top left) the issue to let Google know that you're affected and for the issue to be prioritised. Some of the features you requested is already in development
New IDE features Monaco for cutting edge code editing, streaming logs, reliable debugging and Material design. Seamless integration into the G Suite Developer Hub lets users design, develop, deploy and manage their projects all in one place.
In the meantime, You can use clasp in your local IDE.
Related question:
V8 engine no longer breaks on errors
I've just encountered a really bizarre scenario and can't find any info on this elsewhere. When Xcode breaks at my breakpoints, all keyboard entry for the whole system is unresponsive. I can switch to another app but no key strokes are recorded. Xcode itself is unresponsive to keyboard input.
Anybody else seen this?
I'm running 10.10.1 and Xcode 6.1.
Based on the comments above it would seem that this issue has to do with behind the scenes details of Powerbox. To explain further: my app is sandboxed and calls NSOpenPanel. When breaking (Xcode breakpoint) in the completion block of NSOpenPanel I experience system-wide keyboard input loss.
Keyboard entry behaves normally in breakpoints outside of the call to NSOpenPanel. After working past this area of code I observed that my subsequent operations (queued in the background from the completion bock) often finish before the NSOpenPanel is completely torn down (disappears from the screen). My assumption is that until NSOpenPanel is removed from the screen (and maybe further after), Powerbox won't release control of the keyboard.
Much of this is assumption since I don't have the actual Powerbox code and can't step into it but it seems to fit.
I worked around my debugging issues by utilizing print statements and stepping through code with the variable inspector open. Mouse input continues to function so you can right-click (if you have a two-button mouse) on the variable and print its description at least.
Thanks for the help Ken.
UPDATE
I am now delaying execution of any of my post-NSOpenPanel actions using dispatch_after. On my system a delay of 1 second is doing the trick. I really don't like adding arbitrary delays but this seems to work.
I am a little bit confused if I need to really do anything for fast switching. It seems like if I am not using media element, camera and sockets I get this "fast switching" for free.
I am not sure how to test it though. I see a couple videos where
Hit the Windows Icon(Start Icon)
Hit the back button
or
Hold down the back button till you get the screen view
Go to some other app
Come back to your app.
These both seem to load up fast again but how about if.
Load up app
Hit windows icon
click on tile app
Should fast switching happen at this point or does it load a new instance of your app up killing your old one?
There is different concept involved here:
-the first thing is Fast App resume which is a new feature of windows phone 8 that you can enable so that when you press the application tile it don't restart your app but keep the same instance (by default it will just kill the app and just recreate a new instance exactly as if the app was never opened). You can find more information about that here.
-the second concept is Fast App Switch and Tombstoning. You can find more information about the application life-cycle here. Basically what happen is when you press the windows button or navigate to another app your app will go in dormant state. In this state the application is not running but is still in memory. When you go back since everything is still in memory everything should as it was left off. The main case to handle in case of fast app switch is the fact that when your app is deactivated all the network connection are killed so you should make sure that when you go back you don't display any web error message dialog and that you redo any failed web request.
The second possible state of your application is that after the app is in dormant state you open a couple of app and the device don't have enough memory, then it will choose to tombstone your app. In that state your app is removed from memory so anything you have not saved will be lost. When you go back to your app it will go back to the page where the user previously was and recreate it.
That mean that to handle this case before the app deactivate you should have :
save any context specific data that you might not have been passing by navigation parameter.
maybe save what the user have been currently doing (for example if he is currently entering a long text, it might be better to save it so that the user don't have to reenter it from scratch)
saving the current scroll position or thing like selected items could be a plus
Also when the app resume you have to make sure that you re-query all information that you need. An example of something which would break would be if you load some Data (from a web server for example) in OnNavigatedTo of the main page and then just reuse the data on the detail page without re-querying it. If you are on the detail page press the start button and then do some other and the app tombstonne, when you go back to the app than the data will not be available (since the memory has been "cleared" and onNavigatedTo of the main page is not called since it will navigate back directly to the detail page).
You can use the page state and application state to save whatever information you need to handle properly the tombstoning case. Basically there are dictionary to which you can add some object which will be serialize (so you need to make sure that whatever object you try to save is serialisable) automatically when the app is deactivated.
To test the Tombtonning case easily, what you can do is in the project properties, in the Debug Tab check the check box "Tombstone upon deactivation while debugging". Like this it will always tombstonne the app when you debug and press the windows button or go to another app. To check that it is really tombstonning, when you go back you should see your app showing a resuming screen for a few second (while in the tombstonning case it's almost instantaneous.
So this is a bit confusing. It took me forever to figure out what they really mean by this.
What fast switching references is for more complicated apps. Apps that take advantage of something that requires a saved state.
For example if you are creating a navigation app. You are navigating then you leave the app. When you go back to that app it should show the "Resuming..." indicator and then bring your app back to its previous state.
Here is a Channel 9 video on FAS
http://channel9.msdn.com/events/MIX/MIX11/DVC09
Also here is the MSDN article about it
http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff967547(v=vs.105).aspx
Should fast switching happen at this point or does it load a new instance of your app up killing your old one?
In that case, new instance of your would be launched.
Actually, its a bit confusing, but not that much.
App can be either closed (by Windows key or pressing BAck key for a while) or exited (by pressing Back key in the main menu). Next, app comes to dormant state, it holds everything in memory. ApplicationDeactivated would be risen.
So, if you would just re-activate it (by pressing Back and selecting your app, or by pressing Back only, if you have nothing else in the stack), it would be resumed. ApplicationActivated event would be risen with e.IsApplicationInstancePreserved = true
If you would use lots of other apps (device would run out of memory), your app would go to tombstoned state. Then, you'd be needed to restore all data. e.IsApplicationInstancePreserved would be false.
If you would re-launch your app (by clicking on tile), new instance would be launched, and ApplicationLaunching would be risen.
Fast switching isn't something that really concerns you as a developer. What you need to worry about is "tombstoning" - when someone switches away from your app, you need to save the state: when the user switches back to it, you as the developer have to assume that your app was actually restarted from scratch and needs to reload that saved state. That's the difference between Application_Launching and Application_Activated (user started your app anew from the start screen, vs. app was suspended and is now being resumed, but from scratch).
At some earlier point this was the only way app switching worked. Fast App Switching was added later on and simply changed the contract such that sometimes your app would be resumed where it left off without being tombstoned. It depends on memory, etc, but it is simply a benefit to the user who will, in many cases, no longer need to wait for the app to reload its tombstoned state. You as the developer still have to assume you'll be tombstoned.
I'm writing WPF application
application targets all sort of windows and low performance computers
so I want to write launcher/splash screen for it which will be displayed before application loads
I'm not sure what language to use or what technology
I want it to be very fast and lightweight
can you suggest anything ?
Displaying a flash screen is as easy as popping up a dialog. If the dialog has the various resources such as bit maps already included then it is quite fast. However one issue that will determine this speed is how much other stuff is being initialized at application startup before the code is hit to display the dialog.
So one option would be to have a very simple application that does nothing more than display the flash screen and then start up the actual application. A simple Windows dialog application would do that. You would need to figure out how to synchronize the actual application finishing its initialization and the launching application stopping if you choose this route. There are several techniques for this and the most likely would be to use an interprocess mutex or perhaps just look for a file to be created.
For a point of sale I work with that is launched as part of turning on the terminal we ran into problems in which the application would start before some required system services such as database manager were up and running.
We have found that some environments require much more time than others so a registry variable makes it easy to tweak the delay in the field.
So as part of the application initialization what we did was that when the application starts up, it displays a dialog with a progress bar. The progress bar does a count up and we have a loop that does a one second sleep then increments the progress bar.
The number of seconds to wait is a registry setting for the application with a default value.
One problem we ran into was that when doing development and testing in a debugger, the default value was way too long for impatient programmers wanting to get started so we have condition compile so that if it is a debug compile, the delay is set to a couple of seconds. Otherwise the default is 10 seconds. However it can be changed with a change in the registry value.
See also this Stackoverflow about a launcher.
If you want something realy fast and lightweight, C would be nice.
If you dont want to learn C, you can also make a console application with .NET and C# it's fast too
Edit for comment: You can use a library like SDL wich is very fast and powerfull, and can draw images from a console application.
I'm curious as to how the CodedUI Test functionality in Visual Studio works.
I can see how it can identify keypresses and what's typed by querying the keyboard state, but I'm having a hard time figuring out how (i.e. code-wise) it identifies what button was clicked, where that button is located, and how to track it if between the recording and test runs the button has moved or happens to be scrolled off the screen. I'm mainly interested in items which are foreign to me (i.e. I don't have access to the source code and/or it's running on a different process from my programs process).