I have subclassed NSComboBox for a number of reasons, including a strategy for displaying contextual menus without the OS adding arcane things to them. (“Add to iTunes as a spoken track”???) Here are my mouse event methods:
public override func mouseDown (event: NSEvent)
{ NSLog("mouseDown")
if NSEvent.modifierFlags().contains(.ControlKeyMask)
{ self.rightMouseDown(event) }
else
{ super.mouseDown(event) }
}
public override func rightMouseDown (event: NSEvent)
{ NSLog("rightMouseDown")
super.menu?.delegate = self
super.menu?.allowsContextMenuPlugIns = false
super.menu?.popUpMenuPositioningItem(nil, atLocation:
self.convertPoint(event.locationInWindow, fromView: nil), inView: self)
}
The rightMouseDown method does the last-second menu configuration I want. And I think the (left) mouseDown method would also work (it’s there only because ctrl-left-click is a traditional alternate to right-click), except that with the control key down it never sees the mouse event. The event seems to get to the superclass by going around rather than through my subclass, because NSComboBox does display a menu, just not the one I want (and the menu delegate isn’t right, etc).
I suspect there is some kind of legacy propagation path for ctrl-left-clicks, from the era when Apple mice had only one button. If I knew where these events were directed (I don’t think they’re going to my NSPanel), I might be able to intercept them. Does anyone know where they go? Is there something in NSEvent documentation I’m staring at and not seeing?
