I am fairly new to XCode and the Objective-C language.
When I am instantiating a class, for example an NSMutableArray, XCode will provide a whole lot of auto-complete options. Even for an empty class which simply extends an NSObject has many options, most of which seem completely useless.
What is the reason for having so many auto-complete options, or can they be "tamed" in the preferences?
EDIT: this is unintentionally a duplicate.
The auto-complete makes coding way faster. For example, in [[NSMutableString alloc] initWithCapacity:5], I only had to type the characters that are in bold face, which is ~ 10/38 = ~26%, so it saves a lot of typing.
That said, it is sometimes unwelcome. You can adjust in "Code Sense" in the Xcode preferences (type COMMAND+COMMA while Xcode is open and in the foreground). You can set the delay for suggestions and also whether it should remember functions you've previously used in that project. You can also disable it completely, if you want to. I don't think you can limit the number of functions it considers, though.
Related
Is there a way to modify Xcode's (6.4/7.x beta whatever) code completion in such a way that neither the methods nor the properties of NSObject in a subclass of it are shown? I think, I don't use them frequently and it is pretty annoying when searching for another function whose name I can only slightly guess and then have to scroll through all the unnessecary suggestions coming from NSObject.
Thanks for your help
Not sure that its possible to adjust autocomplete only for NSObject and descendants (of course it might be the way), but there is another nice tool I'm using:
https://github.com/FuzzyAutocomplete/FuzzyAutocompletePlugin
It won't solve a problem of unnecessary suggestions you see, but
it's easier to add and remove from Xcode (comparing to manually internal Xcode files edit)
it solves a problem of "searching for another function whose name
I can only slightly guess"
So not really sure how to even google search this question... But, I'd like to make an NSWindow, reside in the back of all other windows/apps & I want it to be displayed on every Mission Control space (still in the back).
I've seen other applications that do this, so I know it's possible, just don't know how.
(I'm referring to Lion's function called Mission Control where you can switch through different spaces.)
Found the answer, there's a method/enum to make it so that the window will appear in all "spaces" (mission control).
[self.window setCollectionBehavior:NSWindowCollectionBehaviorCanJoinAllSpaces];
And a method to keep the window to the farthest back possible.
[self.window setLevel:kCGDesktopIconWindowLevelKey - 1];
All you have to do is use these two methods, and it'll do exactly what I requested. However, I wish there was a way to keep it from animating when coming down from Mission control (there is non to my knowledge).
You want to set the NSWindow's level and collectionBehavior properties.
The window level you'll want to use will depend on what behavior you're after from your window. You can find constants for the available window levels in CoreGraphics/CGWindowLevel.h. I'd suggest trying CGWindowLevelForKey(kCGDesktopIconWindowLevelKey) ± 1.
Which collection behavior you specify will also depend on what behavior you're after. The brief description in your question suggests that NSWindowCollectionBehaviorStationary | NSWindowCollectionBehaviorCanJoinAllSpaces may be a good starting point.
Does Xcode have a way to show the caller function of a method? I want to know all of the calling functions of a method in a class. A solution would be to find the method in the project, but sometimes different classes have methods with the same name - That could find us a method we're not looking for..
Many other IDEs have this capability, such as Visual C++ 2003/2005/2008,Eclipse ...
Can you do this in XCode?
Xcode 4.4 intrudced this functionality:
New Features in Xcode 4.4 (Scroll down to 'Find and Search Additions')
Move your cursor on top of the function you are interested in
Open the Assistant editor(⌃ +⌘+Enter)
On the top of the assistant editor, Select 'Callers'
You will see a list of all the function that's calling your function
Not the as effective as other IDEs, but does the job.
Yes. Set a breakpoint inside your method, then when it breaks, there are two spots to see a stack. First is in Xcode's "console" area (usually the bottom middle), there is a top-bar which may not immediately appear to be navigable, but it is a select-style UI control which has the entire stack in it. Selecting a different level shows you that scope's variables, etc. and pops your editor to that exact file (where you can mouse-over variables to see their in-memory real-time values). Second is in the left-hand area (where you normally browse files). There is another tab there (besides the file browser) for exactly this purpose. There is a slider at the bottom which controls how many "steps" in the stack you see; clicking on one has a similar affect.
For simple refactoring such as method re-naming, you can use the contextual-menu when you right-click a selected method-name, and Xcode will replace all identical selectors in your project. However, this does not address what you mentioned about different classes having methods with the same signature. It does, however, give you a very nice interface for reviewing the changes in-context and easily accepting or rejecting them one at a time.
It might be noted, however, that changing method signatures often may be a sign of poor design, and particularly if you have to do it with methods which have the same signature on different classes (which are not "siblings" and therefore should both get the rename)
I'm relatively new to Cocoa and I would like to implement the ability to add or delete items from a pop-up menu in the same way that the OS X System Preferences/Network Location pop-up works. Selecting the 'Edit Locations...' option rolls down a window that provides the ability to add to, or delete from the existing Location list. My interest in doing things this way is as much about conforming to the relevant Human Interface Guidelines as having a way to dynamically change the menu content. (I have no real problem with the 'background' coding side of things, it's the user interface that's my primary issue at this stage.)
Is this a standard IB View?
On the surface, I can't see anything appropriate, but maybe that's just my inexperience. I'm assuming that, because this is not an uncommon sort of requirement, the task should be pretty straightforward and that Apple, or someone, would even have a relevant code sample to show how to define such a window.
Can anyone point me in the right direction?
Sorry for the late answer. I found this tutorial: http://cocoadevcentral.com/articles/000014.php
I'm new to Objective-C, Cocoa, Xcode and Interface Builder. I've got some C background in the past, as well as a fair amount of RealBASIC experience.
I'm working through Mark and LaMarche's iPhone 3 Dev book and I'm really just sort of stunned about how tedious some things are. Maybe someone can shed some light on this for me. My question really is, why does the process for seemingly simple actions involve such a complicated number of steps? Is there a benefit to the complexity which I'll come to love later? Or is it just a brute fact that is unavoidable?
For example, in RealBASIC, if I want a slider's value displayed in a text box, I simply add:
myTextBox.text = mySlider.value
to the slider's Changed event. I can program this in well under 1 minute.
In Xcode/Interface Builder, I have to physically type a declaration for both the text box and the slider, then type a property/outlet declaration for each as well, then create a method declaration and implementation for the ValueChanged even, then set up a (relatively) complicated typecast of the slider's integer value into an NSString using initWithFormat. I then have to return to Interface Builder to link up the controls with the control and method outlets I typed in. I don't see how this can be done in much less than 10 minutes. Maybe 5.
So, what's the benefit of this? Why doesn't Interface Builder automatically create, or at least suggest, control declarations and #property statements, as well as method declarations and implementations? Why can't double-clicking a slider in IB offer you a list of events and offer to automatically insert a skeleton method into your .h and .m file? And why does IB even have to be a separate application?
I'm willing to accept that some of this is my unfamiliarity with all things Xcode, but is this really as efficient as the development environment can be?
My apologies if this is a dead-horse, flame-bait topic with opposing sides on full aggro. If so, please just say "yes, that it is" and move on.
Thanks,
-Rob
A lot of the reasons behind the way IB works will become more clear as you get used to the MVC paradigm.
Once you start using Cocoa Bindings, which update your model when the UI changes and vice versa, you should see an enormous productivity improvement.
I too used to think that Xcode and Interface Builder were unnecessarily complicated, until I worked through a book on both (specifically, Beginning iPhone Development: Exploring the iPhone SDK).
If you're serious about working with Xcode and Interface Builder and are as confused as I was when I started, I highly recommend picking up a book like the one I used. Granted, that was for iPhone development, but I think there is another book by the same publisher (or author) that is straight Mac programming.
Once you work through it and understand what is going on behind the scenes it starts to make a lot more sense. In some ways I prefer IB to things like Expression Blend or XAML for WPF programming in .NET.
Give a book a try and see if it helps :-)
Good luck!