If I remember correctly, it use to be possible to add external object placeholders to a NIB in interface builder. This was used to add reference to existing instances of objects that the NIB doesn't create but need to be referenced by other objects in Interface Builder. Similar to "File's owner" and Application objects.
I also found some mention in older SO questions of this technique, for example here
I am using Xcode 5.0.1 on Mavericks and there is no trace of these "External Objects" in interface builder. It seems that it is not possible to add anything to the placeholders anymore. I went through Xcode's release notes since Xcode 4.0 and there is no mention of this being removed (although there are few mentions of dragging placeholder, whatever that means).
So, any idea if this was intentionally removed? A bug? Is there any workaround or replacement for this feature?
Open the project which has already used external object, you will find 'external object' in the interface builder. So I guess the external object may be deprecated and not appear by default.
For an alternative way, you can use 'object' instead.
Related
I'm creating an assistant sheet in my storyboard in interface builder. The viewController contains an NSPredicateEditor and is connected to a property of the viewController using cocoa bindings.
However, I'm not able to properly configure the row templates. When I uncheck one of the predicate operators, I'm not able to re-enable them, nor I'm able to use any of the other provided operators.
Doesn't Xcode support NSPredicateEditor anymore, or am I doing anything wrong here? Just to be clear, I'm not having any code jet.
This is a bug in Xcode. I tried this with and without storyboards and had to force quit Xcode in both cases while configuring the binding. Close and open the project and try to modify the row template before doing anything else.
I used the symbols navigator(cmd - 2) in xCode extensively between different methods and properties in my classes. I then put an extension on one of my classes. The symbol navigator now shows the methods and properties not in the extension and a drop down menu for the all the methods and properties in the extension. The problem is this includes every methods and property in the extension of the class which is so many more than just the ones I have added myself (e.g ones cocoa has). There's probably 400 so I lose the quick navigation ability I had. I was wondering if there is anyway to get around this problem and only show the extension properties and methods I had written myself?
I can't include a link because I am new to the site but here is what happens when I click on the drop down menu. http://imgur.com/a/UQF4P
This is in Xcode 4 and it leads me to believe that I can create, and reuse, custom objects. However, I can not find any method of doing so.
How do you use this? Does anyone know?
Short answer: you currently can't use the Custom Objects section to create custom objects.
The Custom Objects section contains third-party Interface Builder elements. Older versions of Xcode and Interface Builder supported the creation of custom user interface elements. BWToolkit contains examples of custom elements. If you open an old Xcode project in Xcode 4 that contains custom elements, those elements appear in the Custom Objects section. Xcode 4 does not currently allow you to edit xib files that contain custom user interface elements, reducing the usefulness of the Custom Objects section.
If you would like to be able to create custom user interface elements in Xcode 4, file a bug report with Apple.
I am trying to build an document-based application for beer reviewing that allows you to enter your notes. I have built the model in Core Data and the view in Interface Builder. Following some Xcode 3-based tutorials, I am told to connect the new NSArrayController to the managedObjectContext of File's Owner. If I try and do this in Xcode 4, a circled exclamation point comes up next to "Model Key Path" in the inspector for the NSArrayController.
I can actually load the .xib file in Interface Builder in Xcode 3, make that connection, and then build it in Xcode 4 and it runs, but every field raises a validation error.
The model has an entity named Scoresheet, which has a property named date, which is an NSDate. But if I link it to the value of an NSDatePicker and try to save it to disk, it says I have "multiple validation errors." How can that be? They are both NSDates, right? Actually, I have the same problem with bindings to everything; none of my UI objects will work with my model.
The only thing I can figure is that there is something going wrong in the connection between the File's Owner and the NSArrayController.
I haven't written any code at this point, because I'm of the understanding I shouldn't have to just to link UI fields and core data. Is it different because I am using a document-based application? (I can't get it to work in a single window app, either.)
An answer of "don't use Core Data" isn't going to be productive; I know I can just fall back on a regular data object. I would like to figure this out in the context of Core Data if possible.
TIA!
(Update: this question seems to be vexing a lot of people. I have consulted the Zarra book on Core Data, the Hillegas book on Cocoa Programming, and two O'Reilly books. They all seem to be based on Xcode 3.)
NSPersistentDocument has it's own managed object context, and you should bind the NSArrayController in your document's xib file to that managed object context.
For example, if your document class is called MyDocument, then Xcode will automatically generate a MyDocument.h / .m / .xib for you. In the .xib, the File's Owner is an instance of your MyDocument class, and you can bind the NSArrayController to this, with the binding File's Owner -> managedObjectContext.
I am running into the same problem (the CarLot example in Chapter 11 of Hillegass, right?)
The following blog entry is from a developer who wrote and maintains an extension for use with NSManagedObjects and considers this a bug in XCode 4 and has filed a report in rdar : http://danieltull.co.uk/blog/2011/04/20/xcode-4-and-creating-nsmanagedobject-subclasses/
I have a machine with XCode 3 on it, I will eventually give up beating on this in 4, create the project in XCode 3 and import it into XCode 4.
Edited to add: Adding the element in XCode 3 and linking the outlet, and then importing the project into XCode 4 works fine, it does seem that this is a bug in XCode 4. I do not get validation problems from XCode 4 doing this.
I want to build a document-based app in Cocoa but so that it can create and handle different types of documents. Think Word, Excel, Powerpoint all in one application, only much simpler. But every window will be different based on the type of document.
For storage I will use CoreData. I think of adding a field that specifies the type of document since they should all have the same file ending.
So without creating several independent apps what would be the best way to go about it? How do I create this in Interface Builder? How do I code this up?
I don't need detailed source code or anything, just the general idea of how to do this, I will figure the rest out.
Thanks in advance!
This is something the Cocoa Document system is explicitly designed to do. Apple provides documentation, but here are the highlights.
Each kind of document is a subclass of NSDocument. If you're using Core Data, base your class on NSPersistentDocument instead. (Apple has a basic tutorial on how to use Core Data in a document-based application)
You tell Cocoa about the kinds of documents your application can open, and which document class to use, with the Info.plist.
Each NSDocument subclass has one or more NSWindowController objects associated with it, each of which represents a single window. If you'll only have a single window, you don't have to subclass NSWindowController. You can put your UI logic in your document subclass. However, for cleaner code, I'd strongly recommend subclassing NSWindowController.
NSWindowController (and NSDocument if you decide not to subclass NSWindowController) can load a window from a NIB you build in Interface Builder. In fact, this is the recommended approach for creating your document windows.
Hopefully this gives you a general idea of how to approach this in Cocoa.
You would start by creating a NIB for each of your document types; and an NSDocument subclass for each (use an existing document-based-app-example-NIB for the setup here). You would then set theses classes to handle your various document types in the property list of the application; insofar as I remember, there are some useful tools for this hidden somewhere in XCode.
Once that is up an running, most of the details should be handled automagically; but you might still have to fudge the File-menu about a bit, and I seem to remember there being some trouble with setting the default document type and whatnot.
On the whole, tho', it's not a lot more complex than creating an app for a single kind of documents.
PS: Do take care to ensure that you really need different filetypes; sometimes it might be more appropriate having several different views of the same file. Just a thought. :)