Note that there are some explanatory texts on larger screens.

plurals
  1. POBring a subview to the top on mouseDown: AND keep receiving events (for dragging)
    primarykey
    data
    text
    <p>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:</p> <pre><code>-(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]; } </code></pre> <p>This works fine and seems to be the "normal" way to do this.</p> <p>The problem is that I'm now introducing some drag logic to the view, so I need to respond to <code>-mouseDragged:</code>. 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 <code>mouseDown:</code>, but never receives <code>mouseDragged:</code> 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.</p> <p>Is there anything I can do that will allow the view to move to the foreground like this, AND continue to receive the subsequent <code>-mouseDragged:</code> and <code>-mouseUp:</code> events that follow?</p> <p>I started along the lines of thinking of overriding <code>-hitTest:</code> in the superview and intercepting the mouseDown event in order to bring the view to the foreground <em>before</em> it actually receives the event. The problem here is, from within <code>-hitTest:</code>, 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.</p> <p>UPDATE | I've actually done this, in my superview, but it feels like a really bad code smell triggering an event from <code>-hitTest:</code> directly.</p> <pre><code>-(NSView *)hitTest:(NSPoint)aPoint { NSView *view = [super hitTest:aPoint]; if ([view isKindOfClass:[EDTabView class]] &amp;&amp; ![(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; } </code></pre> <p>There are two things that feel wrong with this. The biggest is that I'm performing the action before <code>-hitTest:</code> has even returned, then performing as handled by AppKit after <code>-hitTest:</code> 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.</p> <p>UPDATE | This <code>-hitTest:</code> 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.</p> <p>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 <code>[view removeFromSuperview]; [superview addSubview:view ...];</code>.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload