I have an NSView which is registered for a drag operation.
In that view I have a subclassed NSScrollView, which in itself has an NSImageView in it.
When dragging onto the original NSView, everything is fine, other than when I drag over the aforementioned NSImageView, which seems to interupt the drag and I cannot drop onto it (or in fact, the view underneath it.
The NSScrollView appears to ignore the drag and allows that to go through to the underlying NSView, but how can I do that for the NSImageView so that the Drag/Drop registers through itself, it's superview (the NSScrollView) and onto the underlying NSView.
You can unregister the NSImageView as a dragging destination. Its superview will then handle the dragging session, if it's set up to do that.
[imageView unregisterDraggedTypes];
Oh, thanks so much #Steven!
Swift 4.2 and #IBOutlets:
#IBOutlet private weak var imageView: NSImageView! {
didSet {
imageView.unregisterDraggedTypes()
}
}
Long story:
I had this NSCollectionView, which loaded a custom NSCollectionViewItem from a XIB file.
The collection accepts drop operations (collectionView.registerForDraggedTypes([.fileURL])).
But as soon as something was dropped into it and the custom cell was "dequeued" (makeItem(withIdentifier:for:)) -- drop operations stopped working above that specific cell.
unregisterDraggedTypes() fixes the issue indeed. 🎉
Related
I am writing a Cocoa Framework (not an Application), it contains the definition of a customized NSView; the framework will be loaded in other applications, and the customized NSView will be dragged to the GUI of the applications and become initialized
The question is that I want to include a XIB file in the Framework
I want to add a button and a label to the XIB (in the framework), but the view in the application that consumes the framework, won't show the button and the label
I already set the File's Owner of XIB to the custom NSView in the framework
What else should I do?
Have the view load the nib and move the button, label, etc., from the view in the nib to itself.
It'll be easiest to do this just by getting the subviews of the nib's view and doing this for all of them.
If your nib uses Auto Layout, I think you'll also need to bring across any constraints owned by the nib's view, and you may also need to edit or replace any constraints that refer to that view (e.g., if a view is set to be X points away from an edge of the nib's view).
You may also need to do extra work to change the new view's frame, or to change the frames of the subviews (whether by relocation, resizing, or both) to match the frame given for the new view.
Yeah, I just solved the issue, and I hope the details are helpful to others.
In the framework, there is a complicated subclass of NSView, which contains many controls such as NSSplitView NSOutlineView and IKImageBrowserView, NSPathControl and etc; the framework contains a H file, a M file and a XIB file; H and M define the MyView class; in the XIB, there is a View object whose class is MyView.
On the application side, users need to drag a NSView item onto the main window of their app, and assign an outlet to the view, let's say mainView, and in the applicationDidFinishLaunching function of the "consumer" app, the follow code is necessary
NSBundle *frameworkBundle = [NSBundle bundleForClass:[MyView class]];
NSNib *nibby = [[[NSNib alloc] initWithNibNamed:#"MyView" bundle:frameworkBundle] autorelease];
NSArray *topLevelObjects = nil;
BOOL flag = [nibby instantiateNibWithOwner:nil topLevelObjects:&topLevelObjects];
assert(flag);
for (id topLevelObject in topLevelObjects) {
if ([topLevelObject isKindOfClass:[MyView class]]) {
[mainView addSubview: topLevelObject];
MyView* xView = topLevelObject;
[xView setFrameSize:mainView.frame.size];
break;
}
}
In the code above, the XIB files is loaded, thus the MyView object is initialized, then we fetch it out of the XIB, resize it and add it to the main view of the window
I am currently using iOS 6.0.
I have a custom UIView that needs to have a certain size. If I programmatically init the view and add it it's fine. However, I can't find a place where I can set the size of the view in the storyboard.
Setting its size in the storyboard doesn't work because the storyboard thinks it's empty and set it's size to zero. Setting its size in viewDidLoad or viewDidAppear doesn't work because later on the size will be overwritten by _applyISEngineLayoutValue.
You can do that in your Interface Builder. Open the storyboard where you have your view and open the utilities menu:
Then you can select a button that looks like a ruler on the top of the utilities menu:
In that menu you can set the size of your view and how you want it to expand.
Also, please make sure you setted your Class' view in the class inspector:
Image token from this site.
Finally, make sure you override the initWithFrame and initWithCoder methods:
- (id)initWithFrame:(CGRect)frame {
return [super initWithFrame:frame];
}
//Needs to be overrided when you set your size in interface builder
- (id)initWithCoder:(NSCoder *)aDecoder {
return [self initWithFrame:[self frame]];
}
I am facing the same problem, and I think the short answer is: you can't rely on the frame or bounds in the view's init method when using storyboards.
When your view is initialized by the segue, it will call the initWithCoder: method rather than other init methods, since it is deserializing your view object from the .xib file. Before storyboards, the frame and bounds would be set by the time the initWithCoder: was called, but that appears to no longer be the case with storyboards -- the iOS code sets those values later.
I've used a couple workarounds, depending on the situation:
If I know the size of the view in advance (for example a specialty view that only supports one size) I set my own frame in the initWithCoder: method.
If I don't know the size of the view, I defer initialization of size-specific things until my view's layoutSubviews method is called.
If it's more convenient, I sometimes just explicitly do the size-specific initialization in my view's ViewController. (Not pretty, but sometimes quick-and-easy. I'm not proud.)
I have the same problem as you, and when I select the view and switch to the attributes inspector , setting
"Simulated Metrics" as follows, I can resize the view in the Size inspector.
Make sure that Size is set to either "Freeform" or "None"
I have a app out for testing right now that's almost completely done - just a few bug fixes left. Unfortunately, the customer decided that they'd like the entire main page of the app to be inside of a scroll view (so that there's more room for the table at the bottom). I already have everything set up and I don't really want to move everything and change references. Is there an easy way to change the class of the main view to a scroll view? I've already tried changing the class in IB and setting the class type in the init method. If there isn't I'll probably just throw the top section of the view into a nib file and load it as a custom cell.
-EDIT- I ended up changing the class type in IB and then doing
[(UIScrollView *) self.view setScrollEnabled:YES];
[(UIScrollView *) self.view setContentSize:CGSizeMake(0,2000)];
in viewDidLoad. Thanks for the help, wish I could accept all your answers.
When you are referring to [self view], I am going to assume you mean in a view controller. The view of a view controller can be any view that derives from UIView. Thus a scrollview is completely acceptable.
I don't really want to move everything and change references.
what would you have to move? why would you have to change references? Only thing you should need to do is add a scroll view to your view controller, set the view controllers view to it, and add the current view as a subview to the new scroll view. No references need to be changed, nothing has to be moved.
Refer to loadView method in documentation of view controller.
Here is a simple (untested!) example
- (void)loadView {
UIScrollView *scrollView = [[UIScrollView alloc] init] autorelease];
//Set the properties of scrollview appropriately....
self.view = scrollView;
}
Now the root view of your view controller will be a scroll view.
Note
- As the documentation states, do not do this if you are using interface builder to initialize your views/view controller. I could not tell from your description if this was the case or not. If it is, you should be able to change the view type in interface builder.
You need to set the contentSize property of your scrollview.
Since you are using IB, the easiest way to do this is to put all your UI elements into a view and add this single view to your scroll view. In the viewDidLoad method, set the content size of the scrollview to be the same size as the view that contains all your UI.
As an aside, there are much easier ways to reference views than walking down the view hierarchy, as you seem to be doing. viewcontroller.view.something.tableview. Add a connection to the tableview from your view controller in IB and it doesn't matter where that tableview is in the view hierarchy. You'll always be able to reach it from viewcontroller.tableview, no matter how you rearrange your nibs.
I think you have to use a pointer with proper type. Example for Google Maps: let's say you changed you base view's class to GMSMapView.
MapViewController.h
#property GMSMapView *mapView;
MapViewController.m
-(void)awakeFromNib{
[super awakeFromNib];
self.mapView = (GMSMapView*)self.view;
// ... etc.
}
I know that this question must have been answered plenty of times already, but I have no idea why the touchesBegan: is not called in my UIView.
Before I added it in my app, I made a trial project to do some tests. What I did was subclass a UIView where the touchesBegan: is implemented and add this as a subview of another view. The superview has a button which shows the subclassed UIView once clicked. Everything works as expected.
However, when I did the same thing in my existing app, the touchesBegan: method, as well as the touchesMoved:, were never called. Can anyone explain what could be preventing the methods from being called?
I just found the answer to this. I realised that the superview of the UIView has the userInteraction set to disabled (which is the default value). So when I enabled the userInteraction of the superview, the touches are now recognised.
In my case background = UIColor.clearColor() was the reason why touchesBegan was not called. Its obviously not called on transparent elements.
I was struggling on this problem for a while... and i figure it out. I think that the touchesBegan override function listen on the main view: the first one on the storyboard tree of the ViewController! I would love to post an image of my storyboard to be more clear, but i can't! ;)
Anyway, IF you have subviews, they may covers the main view... in this manner the touch wont "reach" the main view.
To avoid this you'll have to set the Background property in the Attribute Inspector to Default for ALL THE SUBVIEWS. In this way the background will be transparent and the touch will be able to reach the main view.
If you don't want to set the background to transparent there is something you can do:
-Add an outlet of your last view (with background set)
-Add a tap gesture recognizer to it
-Handle the tap disposing the keyboard
ES.
In properties:
//The last view's outlet
#IBOutlet weak var ContainerView: UIView!
In viewDidLoad():
let tap = UITapGestureRecognizer(target: self, action: Selector("handleTap:"))
self.ContainerView.addGestureRecognizer(tap)
Outside:
func handleTap(recognizer: UITapGestureRecognizer){
self.view.endEditing(true)
}
All,
So I have a subclass of NSBox and have subviews in it like a label and two imageViews. I have overridden menuForEvent: in it. However, when I click on the NSBox to select it and then later Control+Click on any of its subviews then menuForEvent: is never called.
I don't understand why that is the case.
There is a difference in how control-clicks and right-clicks are handled by NSView (as jfewtr pointed out). Contextual menus will appear for a right-click if the click falls within a subview, but not for a control-click.
I was surprised by this and actually wrote a post about it with more details here: NSView control-click quirks
There are a couple potential solutions, but overriding/customizing your entire subview tree is probably not the best choice. I've found the best fix for this is to display your contextual menu explicitly in your top-level view (your NSBox subclass) for a control-click:
- (void)mouseDown:(NSEvent *)theEvent
{
if (theEvent.modifierFlags & NSControlKeyMask)
{
[NSMenu popUpContextMenu:[self menuForEvent:theEvent] withEvent:theEvent forView:self];
}
}
While it's not great to hardcode this behavior, it avoids manipulating or traversing your entire subview tree, which can incur more problematic side effects/bugs.
You need to implement menuForEvent: in the subviews too, and forward the event to your superview's (NSBox subclass) implementation of menuForEvent:
- (NSMenu *)menuForEvent:(NSEvent *)event
{
return [[self superview] menuForEvent:event];
}
I assumed that it would automatically fall through to the superview without the need for subclassing the subviews. I found that a right-click does, but, for some reason, a control-click does not.