Events to non-frontmost windows no longer working?


#1

It seems that JUCE components no longer respond to rollover and mouse wheel events in a window unless it is frontmost. On the previous version I was using, pre-Cocoa, these events did get responses even when the window was not frontmost. I’m guessing this is a Mac-only problem, but I’m currently working only on Mac so I’m not sure of that.

I updated JUCE from SVN today and built the demo app as well as the demo plugin without making any changes. Both the app and the plugin (in AuLab) show this behavior. Moving the mouse wheel over a slider in the demo app has no effect unless the window is frontmost.


#2

Hmm. Ok, I’m looking into this at the moment…


#3

On further inspection I think this is an AULab-only problem. I did see the same symptom in Logic at one point, but I can’t make it happen consistently like it does in AuLab.

mac OS 10.5.6
AULab 2.0.1
Juce Demo Plugin, most recent

best,
Randy


#4

The problem is that on the mac, the currently-active window gets ALL the mouse events, even ones that happen above other windows. You’ll notice that in most official mac apps, the non-active windows never respond to mouse-move events until you click them.

In a juce app where all the windows are juce windows, it’s possible to work around this because whichever window gets the event can redirect the event to the appropriate place, but that’s not possible in a hosted environment. I the old carbon code I used to poll the mouse position and fake these events… I just need to decide how best to fix it properly…


#5

I just tried having iCal and Mail over each other. With Mail at the front I could scroll my calendars in iCal with a two finger trackpad scroll. I could also scroll my emails in the same way while iCal was in the front…?


#6

Perhaps unrelated, but some time back I noticed that on OSX the ApplicationCommandManager does not seem to react to commands when the app has focus.

The situation I encountered this under was somewhat bizarre, and I was doing something hacky anyway, so it just forced me to fix things. However, for illustration’s sake, what I did was:

Two apps connected via a network layer. One sends an instruction. The other receives it, and triggers an ApplicationCommand. However, because the second app was not focussed, the ApplicationCommand was ignored.


#7

Beginning with 10.5, NSScrollWheel events are sent to the window under the mouse, whether the window is active or inactive. (from Cocoa Event-Handling)

Likewise in 10.5 and up you can make an NSTrackingArea Object with the option (NSTrackingActiveAlways). This will track mouse movements whether or not the window is frontmost-- no polling should be needed.


#8

and in firefox, mouse-moves still get through to it when anything else is in front (e.g. the dashboard!)

I experimented with those, but had problems when you’re mouse-dragging. When the mouse is down, you want all the events to keep going to that window until they let go, regardless of where the mouse goes, but with tracking areas, it loses the drag as soon as you move outside the window. That’s probably why apps like firefox cheat by polling the mouse pos.


#9

That makes perfect sense.

I do have some repeatable examples of problems in both AuLab and Logic now but I have to focus on other stuff for a bit. The very brief story is that I am seeing crashes in getMouseXYRelative in MidiKeyboardComponent’s timer callback. Bringing up two copies of the demo plugin or two different plugins with MidiKeyboardComponents seems to make this happen regularly. When I can I’ll spend more time investigating.