I come from Eclipse, I would like to know if there is a way in Xcode 4 to navigate through method calls like there.
I know I can jump to the definition of a method, but I want to know who is calling that method/function.
The only way I've found is doing a regular text search, but that's not very helpful.
Since Xcode 4.4 the feature to look up the immediate caller and/or callees of a method has been available. Unfortunately, there doesn't seem to be a handy hierarchy view as there is in Eclipse.
What's New in Xcode 4.4
Xcode can show the callers and callees of the current function or method. This function is accessed from the Show Related Items menu, or by using the Assistant editor and selecting Callers or Callees in the jump bar pop-up menu.
here is a visual how to find the caller(s). Look for the little image i've highlighted in pink.
Doing a search is indeed the only way to check where in the code certain messages are being sent. Xcode doesn't have such a functionality. Keep in mind that even if it had, it couldn't be perfect because messages can be composed and sent dynamically at runtime.
Related
When I'm working in IntelliJ, I often get this popup window that helps to see what method signatures I can use.
It's helpful sometimes, so I don't want to disable it, but in certain situations like this, it blocks my view and I don't know what I'm doing. Is there a way to move the position of this pop-up to under the code being typed instead of above? Basically, I'd still like the pop-up, but I'd like to see the code above it.
I'm working on wrapping some Cocoa functionality in an Objective-C library that will be called from a cross-platform C library. One of my goals is to provide someone who does development in C on Linux with the ability to deploy to OSX without having to get into XCode, nib files, etc. I want them to be able to compile and link their code on OSX using the command line tools, and end up with a regular resizeable main window with the usual buttons and so on, an application menu and a dock icon that looks and behaves as expected, etc.
I'm working on OSX 10.8.5. I have XCode 5.0 installed. Here's my gcc --version output:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
I've figured out how to present a main window, how to set up the application menu, and various other things, programmatically, without using XCode or any nib or plist, but I've run into a problem with the dock icon.
I set a custom dock icon image by calling:
[NSApp setApplicationIconImage:dockImage];
When the user quits the app, the dock icon image reverts to something else (some kind of default application icon or view), briefly, before going away. How can I prevent that from happening without using XCode to create a nib or a plist?
I've tried setting the activation policy of NSApp to prohibitted in the app delegate's applicationShouldTerminate method, to try to hide the dock icon before this switch back occurs. That didn't help, it does hide the window and the dock icon, but the dock icon still switches back to the default icon, briefly, as part of the process of hiding. I confirmed this by returning NSTerminateLator, and confirming that setting the activation policy to prohibited does cause the dock and the icon to hide even though the app is not terminating, and not setting it leaves it unhidden.
I've tried subclassing NSApplication and overriding the setApplicationIconImage call. I have confirmed that it is being called a second time, by something other than my code (well, or not directly by my code, anyway), just before the program exits. I've tried preventing the second call to it from working by calling the super function the first time, but not the second time, and I've confirmed that code in that function can prevent my code from changing the application icon, but that didn't fix the problem. It still happens anyway, somehow.
I've also tried removing the application badge, like this:
[[window dockTile] setShowsApplicationBadge: NO];
just in case it was something to do with that, but that didn't work. The docs say that app badges are no longer relevant as of 10.6, but I was grasping at straws.
Being stumped on the programmatic front, I'm now trying to find out how to package an .app from scratch,without using XCode, and see if maybe I can create a plist from scratch that has a reference to application image in it. But a programmatic solution would be preferable, as I'd really like to minimize what goes into the OSX-specific packaging of a deployment.
Another possibility might be to use XCode once, to produce a very generic, bare-bones .app that my deployment scripts copy and alter.
Please don't shoot my question down as being "too broad" or "not constructive" or something like that. I realize I'm reinventing wheels that already exist in various forms, but there's no law against trying to build a better mouse trap, or just a different or even a worse one, for that matter. I realize I'm trying to fix a problem that a lot of people would consider inconsequential, but XCode-produced apps don't have this problem, and I really don't want the tools I'm creating to produce any user-visible artifacts like that. I'm not intending to diss Apple's tool chain or invite debate about whether or not what I'm pursuing should be pursued. I have a specific, technical problem that I'm looking for solution to that is within the constraints of my goals.
So I am making an xcode application for OS X, and so far things have gone well. However, right now I am at a roadblock. My app is mostly one window, and I need that window to be created multiple times, in the way that apps like Safari, TextEdit, and all those ones have the File>New function. I am new at Xcode, and I was wondering if there was an easy way (hopefully 3-4 lines of code) to do this. If someone could explain that to me that would be great.
Thanks!
Start a new OS X project and choose "Create Document Based Application" . This will create a NSDocument subclass.
If you want to use Core Data , choose that also. This will create a NSPersistentDocument subclass.
This will give you the basis of your application with all the functionality you ask for.
Have a look at Document Based App Programming guide and NSPersistentDocument Class Reference
Whatever you do, dont try to bake your own. There lies madness.
The project template sets up the info.plist correctly to make this work.
Whatever I tell you, it won't involve only "3-4 lines of code," unfortunately.
If you're working from a non-document-based application, you'll want to factor out the code that creates your one window. If you're not using a window controller in concert with your window, you should implement one. Then you can implement an action that will create a new instance of your window controller, and so a new window. Of course, you'll need to add more infrastructure if you're interested in saving information associated with a window to a file.
Which leads me to your other option, which is to create a document-based application. The big advantage here is that, if you're interested in saving the window contents to a file, the infrastructure for doing so is provided. This involves starting over to some extent, but since you've already got the guts of your application working, you'd simply transfer those guts to the document subclass that is provided for you. You'd also need to provide to your project meta information describing the kind of document it is, including the file extension describing it.
Best wishes to you in your endeavors.
I have created a NSStatusItem and I have assigned two key equivalents within interface builder (Xcode 4.0). These are for the preference menu cmd-, and the quit option cmd-q. Both of these will work when the Menu is highlighted/open but will not work otherwise even if the application is the foremost. Any ideas on why this is happening or how I can change this?
The operating system passes key events that it doesn't handle to the front application, which compares them to any key equivalents in its main menu and current window. They are not compared to items in the status bar, and since the status bar is actually a different application, it won't matter that your application is in the foreground. When you have the menu open, it is the window in focus. This is why it works in those circumstances.
Since the status item is only active while the menu is open, you need to get the key equivalents using one of two other methods. The first, newer method is to use event taps. I have never used this, so I can't advise on how to set it up. The other, older option, is to use hot keys. This method may become unsupported in the future, but if you are interested I posted an example in this answer.
My guess: your NSMenu is not in the responder chain. If you can figure out how to get it in there, you can probably get this to work.
I am a newbie in Mac application development. I want to write a GUI application in Cocoa using Interface Builder. I want multiple screens i.e. when one button on a screen is clicked, another screen should be displayed. How can I activate a new screen at button click event?
I would heartily recommend Aaron Hilegass's book Cocoa Programming for Mac OS X. It took me from feeling like everything was impossible to being relatively competent in the space of a few short weeks. I was very impressed with it.
Apple's documentation is amazingly good, but it takes a while to get used to the style, and you will need to know which objects actually exist before you can look up how to use them, which is where Aaron's book comes in.
Your library may have a copy of it, or be able to order one for you if they don't.
I think you mean windows, not screens. Screens are the displays (monitors) on which all the user's windows from all the user's applications appear.
And I second Jonathan's recommendation of the Hillegass book.
The button has a target. That should link to the new window. As its action you can tell the window to show itself.
Take a look at:
http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/WinPanel/WinPanel.html
I think what you want is the type of interface like that seen in Coda, or System Preferences where there is a toolbar on the top of the screen that can be used to select between the content of the window.
The simplest method I have found is to use BWToolkit.
Another method is to use a series of views, and switch between them when the toolbar is clicked. I've found one description here, but that's not the one I used first (which may have been originally in Ruby Cocoa, IIRC).
NSTabView.