One of the features I use a bunch in larger code bodies in XCode is the ability to delineate/label blocks of functionality with // MARK: comments. These get used by the IDE to label things in the menus. I'm porting an app to AndroidStudio/Kotlin, and really missing this. Is there anything like this? I've found the Structure view, but I don't see any hints that comments influence it at all.
Not exactly the same but you can do:
//region RegionName
... code ...
//endregion
and you'll be able to fold this section of code.
Related
I may need to change toolbar background, heading font and position.
Is it possible to do that with the standard CPToolbar? I was looking through the ThemeDescriptors.j, and there is nothing about a Toolbar.
It seams not so difficult to create my own. Should I go that way?
The toolbar isn't themeable as is (although, feel free to implement that for us. :) )
That said, you could do something like this depending on what exactly you want to do…
https://github.com/cappuccino/issues/blob/master/Client/AppController.j#L273
I've looked everywhere for a feature like this. I use the Aptana IDE (which is based on Eclipse) for my php development, and I use the outline feature a lot.
I enjoy xcode's 'pragma mark' feature, which lets you group sections of your source code together in the outline view for quick reference. (Described here: http://cocoasamurai.blogspot.com/2006/09/tip-pragma-mark-organizing-your-source.html)
Is there anything like this for Aptana/Eclipse?
[EDIT: I wrote this blog post which explains further: https://peacocksoftware.com/blog/create-pragma-separator-eclipse-xcode ]
The closest I have found is to do one of these two things:
Create a dummy constant, or create a dummy function. Both will create entries in the outline. See screenshot. Personally, I think I like the constant better, because its icon in the outline makes it clear it isn't really a function.
I'm using #pragma mark - Description all over my source code to use with the XCode4 Jump Bar. This is a pretty handy feature all most you already know.
But right now I'm having a big .h/.m file containing all my business logic classes (RMCategory, RMProduct, RMCountry, RMAddres, ...) and my jump list is starting to look overcrowded.
Is there any known way to disable some items in the jump list? Specifically, I'm looking into hiding the ivars from the .h jumplist. Is there some directive like #pragma hide ivars?
I've been trying to search other supported #pragmas specific to XCode but haven't been able to found anything apart from the classic // TODO, // FIXME et al.
OK, so I've been told by Apple staff at their dev forums that this was currently impossible. I've filed an enhancement proposal there.
I want to know how to do something like Adium does, where when you type more text than the field can handle it expands into a new line. Like this:
Either how can I do this, or where in the Adium source code can I find this?
The view in Adium is AIMessageEntryTextView, plus its superclasses AISendingTextView and AITextViewWithPlaceholder, and the actual resizing (as opposed to figuring out the right size as a hypothetical ideal) is done by AIMessageViewController in response to AIViewDesiredSizeDidChangeNotification.
Do note that Adium is licensed under GPLv2, so unless you intend to use the same license when releasing your own project, you can't lift any of Adium's code for this purpose.
I am not exactly sure what Adium itself does there.
But I am pretty sure that you could just use NSTextView.
You can find it at the Apple Developer website.
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSTextView_Class/Reference/Reference.html
Furthermore this Tech note for using NSTextField, if anyone wants to do the extra work. ;-)
http://developer.apple.com/library/mac/#qa/qa1454/_index.html
Is there a way to create custom collapsable code regions in Xcode similar to how Visual Studio can fold around #region/#endregion blocks?
It would be nice to throw all autogenerated content into a region that I can fold away until I need to look at it. #pragma mark doesn't seem to do the trick.
See: Xcode regions for a longer discussion, but the answer is, unfortunately, "not without an ugly hack."