Apple makes the point that I will rarely need to subclass NSDocumentController. OK, but I expected to see it somewhere in the project produced from the document based application template. Is it in the project, but Apple has "helpfully" hidden it? Is there something i'm missing there?
Thanks
According to this link there is a default NSDocumentController:
https://developer.apple.com/library/mac/documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/AdvancedTopics/AdvancedTopics.html .
Other sources indicate that the first document controller created becomes the default. Presumably, a document controller inited and allocated in the application delegate would become the default and any hidden attempt to create one would happen later and would be ignored. In this way one could add one's own document controller.
This is probably explicitly explained somewhere, and I missed it. Sigh!
If you've created a Document-based application, you can find NSDocumentController.h in
Frameworks->AppKit.
The easiest way to find this is to put this line of code
NSDocumentController* controller;
Into a .m file, and right-click->Jump To Definition on the NSDocumentController part.
Related
I'm trying to add this feature to my app: when pushing a certain button, open a quick look view of a certain file.
I saw this:
Use Quick Look inside a Swift cocoa application to preview audio files,
but the error written in the comments shows up and the app crashes after trying to go back and forth between files.
Apple's class reference of QLPreviewPanel is quite empty.
Which is a correct implementation? What is wrong in the answer in the question I linked?
Apple's class reference of QLPreviewPanel is quite empty.
They have a lot of bugs currently. You can "View page source" in your browser, or use Xcode built-in help, it's pretty good.
Which is a correct implementation?
It looks like someone has already done it with Swift. I'm not sure if that's the full implementation.
What is wrong in the answer in the question I linked?
QLError() [...] called while the panel has no controller is decrypted this way: some class in the responder chain (your NSView or NSWindow should be there already, unless you have a very complex structure) must respond to acceptsPreviewPanelControl: and two other QLPreviewPanelController methods.
I have been looking through the code and the pdf documentation and I can't find anything that indicates how the StockTrader sample application decides which view (PositionSummary or WatchList) should be displayed by default.
Can anyone explain how this is determined?
If I remember correctly, the stock trader RI uses its own custom behavior named AutoPopulateExportedViewsBehavior. This behavior is different from the one used by Prism as out of the box and is designed to work specifically with MEF. Along with the ViewExportAttribute it register the view in the container while also adding in to the corresponding region at start-up. You can find both of them in the StockTraderRI.Infrastructure project inside the Behaviors folder.
Edit:
Maybe I misread the question. If you are asking how it's determined which view between the PositionSummary and WatchList views is shown first, there is no specific configuration for this. The order is related to what module is initialized first. If you were to move the PositionModule after the WatchModule in the bootstrapper, the WatchList would be the one being shown by default.
I want to start off my new xcode project using 1 nib per controller. By default it seems xcode creates:
1. delegate .h/.m
2. MainMenu.xib
And looking at the targets for the project, I see that the 'main nib file base name' is set to MainMenu, the principal class is NSApplication.
Since cocoa is MVC based, how are things MVC based on the default template?
How can I wire things together with a 'MainWindowController' instead of this default setup? If someone can explain the steps to me that would be much appreciated.
You don't want to subvert or change the default setup, just to understand it and work within it. MVC is a description of responsibility rather than some hard requirement about naming.
The delegate .h/.m is the app delegate by name, but its responsibility is to be the app controller. It gets everything setup when the app starts and deals with application level events. It shouldn't do anything that isn't related to application level management.
The MainMenu.xib is just a container / archive of the first Views and Controllers that are to be created when the application opens.
There is no Model in the template really as all it does is display the main window with a static string on it...
Your goal of using 1 nib per controller is fine, but you should be a little flexible with the naming at first. Because the MainMenu.xib contains the main window it should also contain your MainWindowController. This is perfect from an MVC point of view because you are separating the responsibility.
Then, your future Controllers and Views (in their XIBs) can have matching names to keep everything clear. And you can created your Model separately.
I'm working on an existing project which I basically need to create a .XIB
so I can then put in UIToolbar and UIButtons ect.
On the App already it has a Tab bar but has been inputted through code and not the Interface Builder.
I would appreciate any guidance on my problem.
Kind Regards.
There is no automatic code that does this for you. You'll need to look in the code, find all UIView instances that need to go into the nib and manually create it. Then you'll have to be sure to set the frame of each of them to the same positioning as what is defined in the code. Finally, you'll have to be sure to remove all of that from the code (once it is fully migrated to the nib). Finally, you'll have to be sure that the components are referenced only after the nib has fully loaded (which might not have been the case in the current code).
Why not keep the components in the code (and just use nibs for new views)?
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. :)