I have implemented drag and drop feature in my application. All the functionality are well but when we drag a image in to NSTableView,
- (BOOL)performDragOperation:(id < NSDraggingInfo >)sender
method is not getting called.
Can any one tell me the reason why this method is not getting called?
Even if I implement this one also...
- (BOOL)prepareForDragOperation:(id < NSDraggingInfo >)sender
We need a lot more information.
"...but when we drag a image in to NSTableView"
What do you mean by "image", and where (what application) are you dragging this image from? For example, do you mean an image file (Picture.png) from the Finder that you are dragging to the table view in your application? Or from your own application are you dragging some image from one place to your table view?
Is this your own custom subclass of NSTableView? Because that's the only place that you will see -performDragOperation: or -prepareForDragOperation: being called. By default, NSTableView overrides those primitive NSDraggingDestination methods to implement its own tableview-oriented type of methods like Bavarious mentioned (-tableView:validateDrop:proposedRow:proposedDropOperation:, -tableView:acceptDrop:row:dropOperation:, etc.). If you are talking about the fact that these methods aren't being called in an NSTableView subclass, then remember what the documentation states for -prepareForDragOperation::
This method is invoked only if the
most recent draggingEntered: or
draggingUpdated: message returned an
acceptable drag-operation value
So, first, you need to make sure you've registered for the drag types you want, then you need to implement -draggingEntered.
If, on the other hand, you aren't talking about an NSTableView subclass, but an external controller class, then, yes, those performDragOperation: and prepareForDragOperation: aren't called for it. In other words, if you have a controller class, say, MDAppController, it's set to be the delegate and datasource of an NSTableView, the -performDragOperation: and prepareForDragOperation: of MDAppController won't be called. Those methods are meant for NSView-based classes. For that reason, NSTableView has the following method defined in the NSTableViewDataSource protocol: tableView:validateDrop:proposedRow:proposedDropOperation:. If you implement that in your controller class, it should be called, provided you've set the tableView up properly and it's been registered for the types of data you want.
Related
I have just a minor question about coding style.
I have a subclass of UIViewController which is a delegate to an MKMapView object. Naturally, I have an ivar in my view controller which points to said MKMapView. When I'm writing one of the callback methods mapView:didUpdateUserLocation:, is it smarter to send messages to the passed-in reference of the map view or to the ivar reference of the map view?
I'm aware these are essentially the same thing. I use the ivar reference of the map view object. What are the pros and cons of both styles?
Since you know that both MKMapView objects are one and the same thing, it doesn't matter in this particular case. The reason for the convention requiring the first delegate parameter to be the calling object is to handle the situation when a class is a delegate to more than one object. E.g. if you show two different UIAlertView's in your view controller, and the view controller is a delegate to both (a common scenario), then you want to know in the delegate methods which alert view you're dealing with.
I'm using the excellent NSOutlineView subclass PXSourceList in one of my applications. I'm trying to implement drag and drop to my PXSourceList instance. I have:
connected both delegate and data source outlets in IB to my controller
in awakeFromNib in the controller, set self as the delegate and data source
in awakeFromNib in the controller, registered for dragged types
in the controller, implemented the requisite writeItems: validateDrop: acceptDrop: and
namesOfPromisedFilesDroppedAtDestination: methods and declared them in the controller's .h file
For some reason, the drag and drop methods implemented in (4) are not firing at all. I've tried:
Placing log statements in the drag and drop data source methods - they never get called.
Putting a log statement in one of the other data source method that logs the registeredDraggedTypes of the PXSourceList instance - it always returns the proper drag types assigned in awakeFromNib.
Taking the PXSourceList view instance and unembedding it from all containing views except the NSWindow instance - no luck there either.
Copy-pasting data source code from my application to the sample app that comes with PXSourceList - it all works without modification.
Copy-pasting the working code from the example application into the SK source - it doesn't work.
So essentially I'm in a spot where all data source methods get called except the drag-and-drop methods. It's behaving like I haven't registered for dragged types, but 1) I know I have and 2) the instance responds that it is registered for the dragged types that I set.
Any ideas?
Unfortunately, this is a side-effect of how PXSourceList is implemented; if you look inside PXSourceList.m, it makes itself the delegate and data source of itself (since it inherits from NSOutlineView), implements all of the outline view delegate and data source methods, and when each of these is called, it invokes the implementation of the actual delegate and data source which is being used by PXSourceList with the PXSourceListDelegate and PXSourceListDataSource methods. The reasoning behind this when I built PXSourceList was to have a consistent API rather than mixing and matching NSOutlineViewDelegate/DataSource methods with PXSourceListDelegate/DataSource's additional methods (for badges and icons etc).
The 10.7 SDK (which I assume you're using) added some extra drag and drop methods to NSOutlineViewDataSource. Of relevance here in particular, NSOutlineViewDataSource got the additional method -outlineView:pasteboardWriterForItem: added to it, which is an alternative to -outlineView:writeItems:toPasteboard:.
When you start a drag, NSOutlineView queries the data source (by using -respondsToSelector:) to determine which of these methods it implements and which of these to invoke. Given that PXSourceList implements both, and calls the corresponding -sourceList:... methods on the actual data source, NSOutlineView sees both of these methods as being implemented (even if they're not by your data source), and it seems like NSOutlineView chooses to call -outlineView:pasteboardWriterForItem: if both are implemented. Given that you don't have an implementation of sourceList:pasteboardWriterForItem:, the implementation of -outlineView:pasteboardWriterForItem: returns nil and your other methods don't get called (you can see the code here.)
To cut a long story short...
It looks like for now you'll have to implement -sourceList:pasteboardWriterForItem: instead of -sourceList:writeItems:toPasteboard: (or if you're targeting < 10.7, too, implement both; on 10.6 and below, -sourceList:writeItems:toPasteboard: will be called).
I actually have some improvements to PXSourceList in the works which uses the runtime and should fix problems like these, so keep an eye on the project on GitHub!
I'm learning Cocoa at the moment, and have followed 'generic' tutorials on getting a basic form with a button and label.
With the .xib, I've added an 'Object' (instance of NSObject subclass), and have also created a ViewController class, which I connect to my view by setting Custom Class to ViewController. I then code up my ViewController.h and .m files adding a pressedButton method, and a label (myLabel). This all works OK (ie. the label updates when the button is pressed).
My question is: what am I actually doing with this process in C++ terms (a language I'm more familiar with)? As I understood it, my 'Object' (set to class ViewController) represents an instance of the .xib file (may be wrong here), and with this set to the ViewController class, I'm able to make outlets and actions in ViewController.h/.m, but I'm still not sure what's really going on behind the scenes.
Lastly, the XCode template provides an AppDelegate class 'free'. Given I'm managing my controls via my ViewController class, what would this file/object be used for - is it for application specific things that do not relate to the view itself, or is it also used to manage the controls on the form too (like you see in some tutorials I think)?
I hope, I understood the first part of your question well. The .xib (xml verison of nib file) does not represent a class or object. It is rather used to create a view object with all its subviews (each an object) and link it properly to your view controller.
It is most common and automatically generated that way, that the underlying view within your nib file corersponds to self.view (from your view controller's point of view).
You could access each view created by the nib file by navigating though the subview hierarchy of self.view. Alternatively you could define tags within nib/IB (Interface builder) to access individual view objects more easily.
"Just for your convenience" the IBOutlets were introduced. You can define an IBOutlet in the interface of your view controller and link it using IB to the dedicated object that is created using the xib file.
I am saying "Just for your covenience" because it is not really neccessary, considering other ways of addressing your view objects. But it is more than convenient and therfore strongly recommended and stimply the standard way of doing it.
You could even add further views programmatically to a form/view that was created using IB. You can change properties of those views programmatically.
The view and the subvies are created in that very moment when your view controller is initialized with a nib file using the initWithNibName:bundle: method. Then the nib file (xib these days) is opened, its content is parsed and interpreted and all views are created and added to their superviews respectively and their properties and action: selectors etc. are set accordingly. Again, the whole process is designed for your convenience. You could even create all the views etc. programmatically - witout any nib file at all. The loadView method of your custom view controller would be the appropriate place of dong so.
Second question:
AppDelegate is designed for application wide actions etc. If you can manage everything fine within your view controllers then you would not need to change anything on the AppDelegate.
It is often used as a container for variables or functions of global character (which are then properties and members of the app delegate object). Sometimes you may see it neccessary to override some of the AppDelegates methods like application:didFinishLanuncing or applicationDidBecomeActive.
Strictly spoken, UIApplicationDelegate is no class that you subclass. It is a protocol that you implement. (Very much like interfaces within Java - sort of overcoming the lack of multiple inheritance that you are familiar with from C++).
I'm developing an iPad app.
Now I ran into the following problem. I created a "Custom Class" for a UIScrollView. So in my nib file I have added a default UIScrollView and set the Custom Class to MultiSelectView (which is the custom class I created). Screenshot here.
So in my MultiSelectView I have added some methods that I want to use. This works!
The issue is that I'm wondering how I can initialize certain objects that I need in these methods. It seems like - (id)initWithFrame:(CGRect)frame {} is not called, and neither is - (void) viewDidLoad {}.
Thus, is there a way to initialize a custom (GUI) class?
When you unarchive a view from a .xib file, it is not sent -initWithFrame:, as you've noticed. Instead, it's sent -initWithCoder:.
So, if you've got any UIView subclass in a .xib file that needs custom initialization, you'll need to override -initWithCoder: as well as (or instead of) -initWithFrame:.
Looks like you need initWithCoder, it is called when object is loaded from NIB
Or, better, awakeFromNib. The difference is that awakeFromNib is called when all outlets are connected.
I have an NSTableView which I wish to allow users to drag-and-drop video files onto. When they drop the file, it'll get added as a row in the table view.
How would I go about doing this? Currently the tableview's takes its data from an Array Controller (which takes its data from a NSMutableArray)
I found this documentation, but cannot seem to make it work..
I have..
made a "TableCon" class (which I changed to inherit from NSTableView, not NSObject)
changed the NSTableView class to TableCon
set the NSTableView's delegate outlet to that class
called registerForDraggedTypes in TableCon's init
implemented - (NSDragOperation)draggingEntered:(id <NSDraggingInfo>)sender; (again in TableCon)
..but, nothing, it acts like I never changed anything (no errors), what am I doing wrong?
Edit: I've tried implementing Boaz Stuller's suggestion, and also found this description of the solution (the first reply includes the solution to the first post). So what I have done now is..
Subclass NSArrayController which feeds content to the table view (TableListCon)
Add tableView outlet to TableListCon (and pointed it at the NSTableView)
Implement validateDrop, writeRowsWithIndexes, and acceptDrop in TableListCon
Called registerForDraggedTypes on the tableView outlet.
Again, no errors/warnings, but only the awakeFromNib method seems to be called (None of the other methods are called)
NSTableView handles drag-and-drop differently from generic views, which is overall a good thing. It means that you don't have to manually handle the complicated highlighting, cell tracking and inserting behaviours that tables require.
A description of what is required can be found here. Basically, you still call -registerDraggedTypes: (generally in your -awakeFromNib method) but instead of implementing the NSDraggingDestination methods, you implement the various data source methods associated with drag and drop, which can be found here. You should not need to subclass NSTableView to implement drag-and-drop in this fashion.
Note those are data source methods. You need to hook the table view's dataSource outlet to the class that implements those methods in order for them to be called.
In addition to what Boaz said, it sounds like you're creating an NSTableView subclass and then making an instance of that subclass the delegate of NSTableView. If you're going to subclass, that subclass should be used in place of NSTableView, not in addition to it. Also, it's almost always a violation of concerns to have a view be a delegate for another object.