What do I need to do to have variables display their values in XCode?
I don't have it in Auto pane, and it also does not show when I hover over it. Why is that?
I can go Add Expression and sometimes it will display it correctly, and I can also do NSLog and log it, but this seems really ridiculous in the year of 2013.
I am using XCode 4.6. Am I doing something wrong, or this basic functionality just does not exist?
You can use the local variables section in the content pane to view variable values while debugging:
You can use shift + command + Y to toggle the above pane.
For more information regarding debugging in xCode, check out the following link.
In the console use the command 'po' (stands for print object)
e.g. po [self myVariable]
This will give you more information than this semi-useless variable tree in the content pane.
hints:
1) Make sure your build configuration is set to Debug, or you can't debug local variables.
2) Sometimes you need to debug structs and primitives, in this case use 'p' instead of 'po'
3) you can use dot notation (po self.myVariable), but for some data types this doesn't seem to work. I believe it depends on your xcode version
Related
I am using Sublime Text 3 and am trying to access the command palette using ctrl-shift-P. This shortcut is not working. I am running Ubuntu 16.04. Any help to fix this would be greatly appreciated.
The two main reasons for this sort of situation (regardless of the key sequence in question) are:
A user installed plugin or custom key binding is bound to the same key, which is taking precedence and stopping the action that you expect from happening
Some external process is eating the keystroke before Sublime even gets to see it.
In order to diagnose which it might be, you can open the Sublime console with View > Show Console or by pressing Ctrl+`, then enter the following commands:
sublime.log_commands(True)
sublime.log_input(True)
Once you've done that, press the key sequence in question and check the output in the console. In your specific case, you should see this:
key evt: shift+control+p
command: show_overlay {"overlay": "command_palette"}
Not seeing the command that you expect indicates that some other action is bound to the key in question, and usually the command will lead you to what's causing the problem.
Not seeing the key event means that some external process is eating the key. This could be some global program or it could be something in the OS doing it (in the case of Linux, the window manager).
It's also possible that you see a different key event entirely, which indicates that your keyboard layout is not what Sublime expects.
Depending on the situation you may be able to disable whatever is eating the key. Presuming you can't find what that is or otherwise don't want to disable it, or if the event shows that Sublime is seeing a different key, the solution is to change the key binding.
The procedure for this is to find the binding that's not working and copy it to your custom key bindings, changing the key as appropriate to something that Sublime can see.
For core Sublime key bindings, look in Preferences > Key Bindings to find the key in question. For packages, that's generally in Preferences > Package Settings > PACKAGENAME > Key Bindings.
In your case, the setting is a default key binding, so looking in the default key bindings yields the following binding, which you can put in your custom key bindings and change as needed:
{
"keys": ["ctrl+shift+p"],
"command": "show_overlay",
"args": {"overlay": "command_palette"}
},
Something that I found:
Weirdly my Sublime Text 3 doesn't recognise the command if I use LCTRL abd LSHIFT. Using RCTRL+RSHIFT+p opens the command palette, so try that.
In my case it was an app called https://noiz.io which had stolen this shortcut. It can take a bit of time as there isn't (AFAIK) a way to find the application which is bound to a shortcut.
In my case a Pomodoro app I just installed had a command for starting clock defined with the same shortcut and it was stealing the event from Sublime. Just removed the shortcut assignment and it works now.
I want to write my UI tests so that they test all seven states of dynamic type, from the smallest to the largest. How should I do this?
Can I set an environment variable for the simulator in my Scheme and then just make different schemes?
Or can I set the dynamic type variable programatically in my test?
I'd rather not make a DynamicTypeController and then make it say what type it is, because I'd risk forgetting to use this for some elements, and then not have the behaviour properly tested.
Cheers
Nik
I apologise for the incompleteness of this answer, but it is too long for a comment and there would not be any code formatting.
The short answer is, this is not supported: https://forums.developer.apple.com/thread/21503 , but it probably warrants a radar.
The longer answer is, you might be able to hack something together. The setting for dynamic type in the simulator is available on your filesystem at: ~/Library/Developer/CoreSimulator/Devices/<device identifier>/data/Library/Preferences/com.apple.UIKit.plist. You can programmatically get the path to the simulator filesystem from inside an XCTest using:
let environment = NSProcessInfo.processInfo().environment
if let resourcesDir = environment[ "SIMULATOR_SHARED_RESOURCES_DIRECTORY" ]
{
print( "-- Simulator Shared Resources Directory: \(resourcesDir)" )
let dictionary = NSMutableDictionary( contentsOfFile: "\(resourcesDir)/data/Library/Preferences/com.apple.UIKit.plist" )!
print( "Dictionary: \(dictionary)" )
}
However, the test is sandboxed from the simulator directory, so you cannot actually open or modify the preferences. That code snippet fails when trying to unwrap the dictionary. I also never tried this with Xcode Server.
You could modify the plist using with a shell script like so: plutil -replace UIPreferredContentSizeCategoryName -string UICTContentSizeCategoryAccessibilityXXXL com.apple.UIKit.plist. The simulator needs to restart after you modify the file so this may not fly in a shared build environment. Unfortunately, the path to the simulator's filesystem is not available to Pre-action scripts in Xcode. You could modify the setting for all the simulators, but again, might not fly in a shared build environment.
At the end of the day, you might be better off creating your DynamicTypeController and adding some process to ensure no one uses UIApplication.preferredContentSizeCategory.
This was all tested using Xcode 7.1 (7B91b).
I finished writing a class' .h and .m files in objective c in XCode and want to see if all the class functions are implemented correctly. I have not set up anything in the storyboard file yet but would like to test and debug the code. I'm looking to simply declare an object of the class type and to run some of the functions on it similar to using the command line with Python.
If there's no way to simply debug code using command line commands, what would be the easiest way to set up the storyboard?
You can use the XCTest to test your classes.
You can find all the information you need in the Apple documentation is actually pretty easy to use.
https://developer.apple.com/Library/ios/documentation/DeveloperTools/Conceptual/testing_with_xcode/testing_2_testing_basics/testing_2_testing_basics.html#//apple_ref/doc/uid/TP40014132-CH3-SW1
If you want you can check this tutorial as well.
http://rshankar.com/test-driven-development-in-ios-beginners-tutorial-part-1/
If you want you can set break points as well and check that your code is executing properly. Sometimes when I just want to proof-test small classes I do it just setting a couple of break points instead of the XCTest classes but it all depends on your study case. If you have a decent amount of classes I would suggest to use XCTest to check that the classes are actually doing what is expected setting your assertions and the other conditions that XCTest offers as a framework.
Another way you can do your testing if applicable is using NSLog to print in console lines or values of interest at each stage of your code execution.
You mentioned the command line. If you set breakpoints you can use po objName to print the value or print varName to check values of objects and primitive variables correspondingly. po stands for print object and print well... There's different options if you feel comfortable using the console just set NSLogs at certain point of your code or set the break points and print the values using po or print commands in the console.
Here you can check the string format specifiers for NSLog which are the same ones used for NSString
https://developer.apple.com/library/ios/documentation/cocoa/conceptual/Strings/Articles/formatSpecifiers.html
I ran into a situation that Xcode shows different result of one object from the result of po command in LLDB. firstly, all values in the object is nil and the object is displayed with *const type modifier, which it shouldn't be. and when I use po to get datasource variable it shows correct data. However, it shows datasource is nil in Xcode variable list.( please see following screenshot) Can anyone explain why?
This seems like the sort of thing you should file a bug with Apple about. Probably take more back and forth to figure out what is going on than can be easily done in this context.
As the title said, I want to debug some Core Data bugs. Instead of using NSLog everywhere in the code, is it possible to watch a entity's attributes in XCode 4's watch window? Like the "quick watch" tool in Entity Framework 4.0 of .NET.
Any value that has a named variable assigned to it can be viewed in the debugger. In Xcode 4 it appears in the debugger's left column. If you select the variable, you can use the contextual menu option "Print to console" to have a detailed description printed to the debugger console. This is useful when examining managed objects as they often contain more info than the list of variables can cleanly display.
(See- Xcode 4 Transition Guide:Control Program Execution in the Debug Area and Source Editor, Figure 5-9
In addition, you can issue any of the standard gdb commands from the command line in the debugger console. The most useful of the these commands is po which stands for print object. Say you have an object myObject that has a property aProperty. You could examine it directly by using:
po [myObject valueForKey:#"aProperty"]
If you create NSManagedObject subclasses, you also have the option of overriding the description method which allows you to produce custom descriptions of the object which will show up in print to console and the po command.