Question

Ok, basically I have a view with a series of slightly overlapping subviews. When a subview is clicked, it moves to the top (among other things), by a really simple two-liner:

-(void)mouseDown:(NSEvent *)theEvent {
  if (_selected) { // Don't do anything this subview is already in the foreground
    return;
  }
  NSView *superview = [self superview];
  [self removeFromSuperview];
  [superview addSubview:self positioned:NSWindowAbove relativeTo:nil];
}

This works fine and seems to be the “normal” way to do this.

The problem is that I’m now introducing some drag logic to the view, so I need to respond to -mouseDragged:. Unfortunately, since the view is removed from the view hierarchy and re-added in the process, I can’t have the view come to the foreground and be dragged in the same mouse action. It receives mouseDown:, but never receives mouseDragged: or any subsequent events. It only drags if I leave go of the mouse and click on the view again, since the second click doesn’t do any view hierarchy juggling.

Is there anything I can do that will allow the view to move to the foreground like this, AND continue to receive the subsequent -mouseDragged: and -mouseUp: events that follow?

I started along the lines of thinking of overriding -hitTest: in the superview and intercepting the mouseDown event in order to bring the view to the foreground before it actually receives the event. The problem here is, from within -hitTest:, how do I distinguish what type of event I’m actually performing the hit test for? I wouldn’t want to move the subview to the foreground for other mouse events, such as mouseMoved etc.

UPDATE | I’ve actually done this, in my superview, but it feels like a really bad code smell triggering an event from -hitTest: directly.

-(NSView *)hitTest:(NSPoint)aPoint {
    NSView *view = [super hitTest:aPoint];
    if ([view isKindOfClass:[EDTabView class]] && ![(EDTabView *)view isActive]) {
        // Effectively simulate two mouseDown events in sequence for this special case
        [view mouseDown:nil]; // Works because I know too much about the implementation
    }
    return view;
}

There are two things that feel wrong with this. The biggest is that I’m performing the action before -hitTest: has even returned, then performing as handled by AppKit after -hitTest: has completed. The second is that I don’t have an event to pass, so I’m passing nil. It works in this case since I know the event handler doesn’t actually process any of the event data, but it’s not great. The alternative was to move the entire logic into the superview, but the separation of concerns here feels even worse.

UPDATE | This -hitTest: hack is broken… it gets triggered when I’m not making a mouse click, such as when I’m dragging something over the top of the view. Still looking for a good solution to this problem.

An answer can either literally indicate how a view can leave and re-enter its superview during a drag operation, or (perhaps more elegant), an alternative way to move a view to the foreground other than [view removeFromSuperview]; [superview addSubview:view ...];.

Answer 1

Ok, I went out on a whim and tried something illogical.

Instead of this to move a view to the foreground:

[theView removeFromSuperview];
[theSuperview addSubview:theView positioned:NSWindowAbove relativeTo:nil];

I simply dropped the removeFromSuperview line, wondering what AppKit actually does if you try to add a view to a superview twice (I assumed it provides protection against it happening).

It works, at least under Snow Leopard, and it solves a lot of problems. The view being already present in the superview isn’t added, as the method name suggests, but it does get its position set without having to first remove it from the superview.