I've set the view for my NSStatusItem to a WebView, but I'm not able to capture hover events in the WebView because my NSStatusItem doesn't get focus, like a normal WebView would.
How do I programmatically give my NSStatusItem or its associated view focus so that the embedded WebView will capture mouse events like a normal WebView?
In case anyone cares, one way I can think of is to have the view for the NSStatusItem be a custom NSView that overrides the NSResponder methods mouseEntered:, mouseMoved: and mouseExited:. Then, I would add the WebView as a subview of the custom NSView, and each time the mouse moves inside the NSView, send the coordinates of the mouse to the Javascript in the WebView, which can figure out what element is at the position of the mouse cursor.
Basically, it would be reimplementing mouse hover at its core. Hopefully there's an easier way though.
Related
I have a modal window, which is perfect for iOS 13's drag to dismiss gesture, because this way the user remains in the context, so I don't want to use full screen. The controller contains a UICollectionView which displays a month calendar, which is scrollable vertically.
The problem is, that when the user wants to scroll upwards in the collection view, the dismiss gesture is triggered instead. If I scroll down first, then can I only scroll up.
I've tried to disable the internal UIPanGestureRecognizer (it seems somehow there is no presentedView, so it didn't work), tried to set the UICollectionView's pan gesture recognizer delegate to prevent the system recognizer to fire (it turned out you can't do that), and tried to scroll the collection view on appearing a bit (ugly).
How can I elegantly convince the the modal presentation, that my scrollview isn't scrolled to the top?
I'm currently using a NSPageController to navigate between a Master and a Detail View in my OSX Application. I'm basically using it only to support transition animations, since there is no NavigationController on OSX.
However, the default NSPageController is listening on swipe gestures from my magic mouse and trackpad and changes the displayed view on a horizontal swipe. (like going back / forward in your browser). I would like to deactivate this behavior but overriding and intercepting any gesture method in a NSPageController subclass had no effect so far.
It seems like a NSScrollView / NSTableView does absorb these touches since doing a horizontal swipe gesture above any of my TableViews won't result in a view transition. (It only absorbs them for my magic mouse, doing a swipe gesture on my trackpad still results in switching views)
Target OS: Mac OSX 10.9 +
Thanks for your help!
You can make a subclass of NSPageController and overwrite
- (void)scrollWheel:(NSEvent *)theEvent
This should help.
Could anyone can disable or prevent mouse cursor changed when move mouse to divider of NSSplitView ?
I have a NSWindow with splitView inside, then I try to add a NSView/NSButton to window's contentView to prevent mouse events. What I gain is prevent mouse click, but I need to prevent the mouse cursor changed when I move mouse to splitView's divider below.
So what I try to do is:
Add a view on top to prevent user click on splitView and mouse cursor does not changed.
Like Sparrow app when Ads shown.
Any kind of hint, help, experience is highly appreciated!
On your NSSplitView you could add:
[self addCursorRect:[self bounds] cursor:[NSCursor whateverCursorYouWant]];
Have a look at Apple's sample code DragItemAround
I have 2 subclasses of NSView that are subviews to a common superview. They dont overlap and they both intercept mousedragged calls. When I drag from one of the subclasses to the other the mousedragged function will be called until I release the mouse button even when I drag all over the screen. I though the default behavior was for the mousedragged function to be called only when the mouse was over the bounds of the receiver.
Iam also using NSTrackingArea for mouse enter, exit and move events, but from what I've been reading does not involve drag events
Thank you for your time,
Jose.
You could subclass the NSWindow and override sendEvent:. That way, you can intercept the NSLeftMouseDragged events and dispatch them in whatever way you wish.
I have an NSTextView in an NSScrollView, and I am programmatically inserting an NSView subclass as a subview of the NSTextView. This NSView acts as an overlay, superimposing graphical information about the text beneath it.
I thought it was working quite well until I noticed that the text view does not respond to right clicks. Other operations (editing, selection) seem to work just fine.
Also, if the first responder is changed to a sibling of the scroll view (an outline view, for example) the text view does not regain first responder status from clicking on it. The selection will change in response to clicking, but the selection highlight is gray instead of blue (indicating that the text view is not the first responder).
If I offset the frame of the overlay subview, the text view behaves 100% normally in the area not overlapped by the overlay, but the overlapped area behaves incorrectly, as outlined above.
Steps To Replicate This Behavior on Mac OS X 10.6.4:
Create a plain old non-document-based Cocoa app.
Add an `NSTextView' IBOutlet to the app delegate .h.
Add an NSTextView to the window in MainMenu.xib. Connect the textView outlet.
Type in a bit of code:
In applicationDidFinishLaunching:
NSView *overlay = [[NSView alloc] initWithFrame:textView.bounds];
[textView addSubview:overlay];
[overlay release];
Run the app, observe that right click in the text area does not work as it should, yet you can still otherwise interact with the text view.
Next, add an NSOutlineView to the window in the xib. Observe that once focus leaves the text area (if you click on the outline view) with the overlay in place, you cannot set the focus back to the text view (it will not become first responder again).
Is there some way I can enable the NSTextView to receive all of its events, even though my NSView overlay does not accept first responder or mouse events? I suspect this might be related to the field editor – perhaps it is ignoring events it thinks are destined to the overlay view?
You probably need to make your overlay an instance of a custom view class that forwards all events and accessibility messages to the text view. You may also need to convert any view-relative coordinates to the text view's coordinate system.
I don't have a lot of experience with it, but another possibility would be to use a Core Animation layer as an overlay.
A clean way to handle this is by making your overlay view a custom subclass of NSView, and then overriding the hitTest: method to always return nil. This will prevent the overlay view from participating in the responder chain. Instead, events will get sent automatically to it's superview or views higher up the view hierarchy. You might also want to override acceptsFirstResponder to return NO to be safe (in case it's accidentally set programatically).