FeedTicker
Gee!Even though you subclass NSView and override acceptsFirstMouse() to return true like a good little trooper it doesn't effect right mouse clicks. The idea is that any NSView that returns true for that call will accept a mouse click even if the window it occupies isn't key, that is it isn't the application that currently has focus (isn't the one the user is currently using). This is ideal for the FeedTicker case; if it's scrolling along the desktop you want the user to click on an entry without having to bring the application into focus.
The problem is as I was explaining before is that it doesn't effect right clicks (or control-clicks for our one button mouse friends). Luckily Google comes to the rescue with this message board thread. Specifically this piece of code.
To get it to work you actually have to override NSApplication's sendEvent() method to wire up the right path. The cheesy thing about it is that you have to find which NSView inside which NSWindow captured the original event by cycling through them all and doing a hit test. Annoying but it works.
Well it mostly works. Besides the fact that when I implement this code block I'm actually getting NSRightMouseDown events despite what the comment and second if statement says (maybe he's running Jaguar?) I'm getting some strange behavior when it comes to pop-up menus. When FeedTicker does not have focus and you right click on it to get a menu it appears just fine. The animation stops as a consequence of the menu interrupting the normal event flow and blocking the animation timer; that's all normal. The problem occurs when you make FeedTicker lose focus by clicking on another application or the finder without selecting an option from the pop-up menu. The animation doesn't resume even though the menu disappears. I don't think the menu is actually disappearing though because when the FeedTicker is brought back into focus the menu appears for a split second before blinking out of existence after which animation resumes.
It seems to me there is something else going on behind the scenes with respect to the pop-up. My first thought was that the application didn't really have focus correctly when the right click was routed through but the overridden sendEvent() method specifically calls [self activateIgnoringOtherApps:YES] before sending the event to the window. In this case I would think that the same buggy interaction would occur even if the window already had focus; the act of losing focus should be the catalyst. Of course none of us who has ever encountered a pop-up menu has ever seen that behavior. This is what makes me think something else is going on that I'm not aware of.
It's an odd problem because I'm not specifically opening the pop-up menu. In fact, surprisingly there is no way of explicitly opening an pop-up menu in Cocoa. You can give a NSMenu instance to a NSView and the behind-the-scenes code takes care of the rest (well is supposed to).
As to what should be going on behind the scenes I can't fathom. My only guess is that there is something wrong with the way the event is created in the overridden sendEvent() method. I fixed the eventNumber, clickCount and pressure value assignments since the event I'm getting is actually a NSRightMouseDown. Doesn't make any difference.
BTW, Cocoa's integrated spell check within all text areas is boss.
UPDATE: HA! Changing the code so it doesn't focus the application makes it work. How strange.