I'm trying to set up a QCView inside a Cocoa project but seem to be going round in circles as much of the available documentation is depreciated. I've followed this:
http://kineme.net/forum/DevelopingCompositions/ProblemusingQCPatchController#comment-23250
And got some simple KVC bindings working. But can't work out how to access the published inputs on a code level.
I understand that you can use setValue: forKeyPath: but dont know how to access the Object controller that was created in the IB interface by dragging and dropping.
How can i find out what the active Object controller is called? Once I know what that ivar is, is it as simple as:
[NSObjectContoller setValue:(id) forKeyPath:(NSString)];
Or is there something more to this?
I've managed to work this out myself.
Create an IBOutlet from the Object Controller in your .h file. For Simplicity I'm doing this inside my AppDelegate.h
you can call setVlaue: forKeyPath: on your instance of the Object Controller.
For me this looks like:
[_theObjectController setValue:sender forKeyPath:#"selection.patch.Green.value"];
note that the key path is "selection.patch.Green.value" You need to add your controller key to the beginning of you Model Key Path.
Related
I am working with cocos2d and CoreData. I have imported "AppDelegate.h" but I can't create an object from it. I would think that all I would do is:
AppDelegate *delegate;
When I do this it get an error saying AppDelegate is not defined. The AppDelegate .h and .m files are next to the main file.
Also, when I try to write to a file I don't get an error but it does not write.
The boiler plate code created by XCode (I'm assuming you are using XCode) will create an NSManagedObjectContext for you called *managedObjectContext. If you need to create other objects that are going to interact with your core data model (such as a view controller), you simply pass in that managedObjectContext object as an argument (or link it to a property in your custom class) and interact with it in your custom class. It's worth noting that it's not good practice to be passing around an AppDelegate object in your app. Your app delegate should be at the foundation of your code base and not treated as a typical class. There are definitely times when you will want (or need) to pass the app delegate as an object or reference it in IB, but typically your app will launch in your
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
method and you will launch your primary view controller from there.
Some things in core data also require the persistent store coordinator (such as retrieving managed object ID's), so you may need to pass that in as well. If you need some help working with Core Data, there are a bunch of great articles and books on the subject. I recommend reading as many as you can, since Core Data can be difficult to comprehend at first. It helped me to read a bunch of tutorials at first since everyone explains it a little differently.
Here's a great recent tutorial written on Bindings, Core Data, and working with the app delegate to get you started: http://www.raywenderlich.com/21752/how-to-use-cocoa-bindings-and-core-data-in-a-mac-app
In Cocos2d 2.0, AppDelegate is renamed to AppController
AppController *app = (AppController*)[UIApplication sharedApplication].delegate;
I'm trying to set up a fairly simple view that presents a table to the user. This table is connected to an Array Controller, which I want to use to retrieve records from Core Data. For some reason, I can't seem to connect the 'managedObjectContext' outlet to anything else in my app. When I created my project, there was a property generated in my app delegate which returns the MOC I need, but I can't hook it up in Interface Builder, even after prepending "IBOutlet" to the declaration. Image below showing the available connection on both ends:
http://yada.im/uploads/image/screenshot/1108/7efebc90ca7187a537da9ae003dd5f3e.png
I'm sure that I'm missing some simple step here but I can't tell what piece of glue code I'm supposed to write that will allow me to hook this up more easily. For reference, I've tried dragging a line from the controller's moc outlet to every single source I could think of, and changed the "File's Owner" class to that of my application. Stumped here!
Typically in the template provided by XCode the managedObjectContext comes along with AppDelegate.
You have to bind the managedObjectContext reference of the array controller to the managedObjectContext in AppDelegate.
For this you have to make an object of AppDelegate inside the xib i.e., if its not already present.(Drag an object placeholder from your object library and make its class as AppDelegate)
This makes AppDelegate visible for binding inside that xib.
Next step is actually binding the managedObjectContext. Select your array controller and go to bindings inspector. In the parameters section select App Delegate from the drop down and check on "Bind to".
Fill the "Model Key Path" field with self.managedObjectContext. Now you will find the connection in the connections inspector also.
UPDATE:
The process of creating a new AppDelegate object is to be done only if it is not already present in the main nib file (but the stub generated always has the AppDelegate object in the main nib file).
For a non main nib file, if we follow the above approach, a new AppDelegate object will be created which won't be the NSApplication's delegate. Even though this can be solved by connecting delegate outlet of the application object proxy provided in each nib, the AppDelegate object still won't be the same.
The result is two different managedObjectContext talking to the same store. Although this might appear to work properly when the changes are saved at each step, this is not what we want.
To get the right AppDelegate object, i.e. the one used in the main nib file:
-instead of creating a new AppDelegate object, bind the managedObjectContext of the array controller directly through the application to its delegate. In other words the object to bind to will be the application object and the key path used will be self.delegate.managedObjectContext.
The way to add objects of your entity depends on the specific logic you want to implement.
The generic and easy solution would be, binding the fields for input to the array controller like you might have done for the table and then hooking up the array controller methods to the buttons inside the sheet.
Another option is sub-classing NSArrayController and over-riding the super class methods like add: to write your code (for opening your slide sheet maybe) before calling the super class method, [super add:sender] . Don't forget to specify this sub-class of NSArrayController as the class of your array controller in the xib.
i have been working on moving one of my apps away from the "shared appdelegate" process which seems to be frowned up, despite its over whelming use. i have been attempting to setup protocol methods for what i want to do but am having zero luck. my question is, can you even have lets say a single viewcontroller send delegate requests to multiple classes? from what im finding out it doesn't seem like you can. which doesn't make sense because i thought that was the whole point of delegates and protocols with mvc. now just to clarify, i know you can have a single viewcontroller act as the delegate for multiple other viewcontrollers. but that's not what i am asking. for a simple example, lets say you have apples flip-utility template. the "done" button just calls a delegate method to the mainvc to dismiss it. now lets say we added a new class called...
#interface NewClass : NSObject <TheOtherDelegate>
and it had a delegate method...
- (void)doSomething
{
NSLog(#"The Delegate did something...");
}
can we have a button on the flipsideviewcontroller, that we wanted to call that delegate method, but still keep the "done" button call to the delegate method on the mainviewcontroller that dismisses it?
that being said, i put together a quicky project just to see if it would work and it doesn't. i came across an "answer" that says you have to instantiate the class first you want to be the delegate...
NewClass *myDelegate = [NewClass alloc] init]
[fillInMethodHere setDelegate:myDelegate];
not sure why it got a correct answer check, because needless to say it doesn't work. is there something i am missing? i scoured ib to see if there is some "delegate" connection somewhere but i couldn't find anything.
on a side note, as i was working in my working project, i read a suggestion about removing the #import and adding #class. again, that broke all kinds of things. the strange thing is before doing that, what i had so far was working and building fine. when i removed the new #class and un-commented the #import. xcode all of a sudden gave me an error "cannot find protocol deceleration for..." but yet, it worked seconds earlier. i would up having to remove the protocol code and re-add it for it to work again. very starge.
any help would be appreciated. everything iv read in docs, google, stack, etc that say something should work, don't in an actual project.
A "delegate" isn't some fancy object. It's simply a synthesized property of type id called delegate. If you wanted to, you could have an arbitrary number of properties that all conformed to the same protocol. Then when you wanted to issue a callback, you would just address all of them:
[self.mydelegateA doSomething];
[self.mydelegateB doSomething];
etc.
You could also have an NSMutableArray property that you could add objects to, and then use [self.myMutableArrayOfDelegates makeObjectsPerformSelector:#selector(doSomething)].
Finally, there's always the route of NSNotificationCenter (not to be confused with push notifications) is a class that provides an inter-object messaging system. Many objects can register for a message that any other object can send.
Please see the Apple's documentation for more information. Click Here.
Regardless of the fact that this is OS X documentation, it's still quite good at explaining things visually: click here.
Here's an example of simply changing the name of the delegate property: click here
And here's an example of adding another protocol and a second delegate: click here
Finally, here's an example that builds on the previous two and has a third delegate that also conforms to the same protocol: click here
I am getting incredibly frustrated with interface builder at the moment, and would appreciate some help before I ragequit it and code everything by hand (which seems to be much, much, much easier).
The basic situation is this: I need to make a model variable accessible to each view controller in my application.
The simplest way I can see to do this is to just create a property on the view controllers that retains the model, and to set that after the controller is initialised.
However, I can't find any of the actual initialisation code for the views shown on the storyboard in my project. There's no reference to any of them at all. Does the interface builder really generate not generate any code reference to its controllers in the app delegate?
For that matter, why is there no reference to any of the top level controller objects (tabview, tableview etc) in code at all?
All I want to know is how to force xcode to actually generate the controller creation code in AppDelegate.m - so that I have access to the created instance of the controller - or, failing that, a way to share the model between these amorphous objects.
Maybe it would be easier to create a singleton class where you can store all your global variables and methods. Example here.
You will need to manually create a subclass of your view controller and then override the methods you want to inject code into. In Interface Builder you can then choose to make your View controllers of this custom type.
my question relates to Interface Builder and an IKImageBrowserView not implementing bindings as I would expect.
I have a fairly long key path to get to an NSArrayController, the contents of which I want to display in the IKImageBrowserView.
This is the key path I am binding an NSTextField's Display Pattern binding to:
currentOrder.imagesArray.unvalidatedImages.arrangedObjects.#count of the AppDelegate.
This works fine and gives me the number of unvalidated items in the array of images belonging to the current order, which is what it is supposed to.
When I attempt to bind the following key path to the IKImageBrowserView's content: currentOrder.imagesArray.unvalidatedImages.arrangedObjects of the AppDelegate, Interface Builder gives no error but instead acts as if I hadn't entered anything. When I click back to the inspector, the bindings key path is blank again.
It does however log the following to the Console:
Ignoring exception related to working with bindings: NSUnknownKeyException, [<NSCustomObject> addObserver:<IKImageBrowserView ...> forKeyPath:#"currentOrder.imagesArray.unvalidatedImages.arrangedObjects" ...] was sent to an object that is not KVC-compliant for the "currentOrder" property.
My AppDelegate implements currentOrder as an #property retained and all sub-keys are also #properties. I can be sure that these properties are KVC-okay because the NSTextField above is able to read changes without a problem. Interestingly enough the IKImageBrowserView's selectionIndexes is able to bind to ...unvalidatedImages.selectionIndexes, it's only the content that can't.
I have implemented a workaround whereby I have placed an NSArrayController in my nib file and bound the Content Array to ...arrangedObjects then bound the IKImageBrowserView to the array controller but would be very happy to have a neater solution, or at least to know whether I am doing anything wrong.
Thank you!
Did you try implementing the methods of <IKImageBrowserDataSource> in your app delegate, and using the _dataSource connection instead of a binding? That works for me, and is how the Apple tutorial has you do it.
You basically only need to implement – numberOfItemsInImageBrowser: and – imageBrowser:itemAtIndex: to provide the data, which isn't too bad. The slightly trickier part is to implement an <IKImageBrowserItem> class to wrap your data, but even that doesn't require massive effort. The tutorial linked above should help a lot.