Live rollover offset bug, fix


#1

I found that rollovers in my AU in Live were offset from their correct coordinates. It looked like Live’s main window instead of the plugin window was being used to calculate window-relative positions. In starting to investigate I found a fix. Here it is:

--- a/src/native/mac/juce_mac_NSViewComponentPeer.mm
+++ b/src/native/mac/juce_mac_NSViewComponentPeer.mm
@@ -258,7 +258,8 @@ public:
 
     static const Point<int> getMousePos (NSEvent* e, NSView* view)
     {
-        NSPoint p = [view convertPoint: [e locationInWindow] fromView: nil];
+               NSPoint pw = [e locationInWindow];
+        NSPoint p = [view convertPoint: pw fromView: nil];
         return Point<int> (roundToInt (p.x), roundToInt ([view frame].size.height - p.y));
     }

In other words, using the temporary NSPoint as an argument to convertPoint allowed this bug to happen. Normally if a temporary is causing problems I would think “compiler bug?”, but since this is host-specific it’s mysterious to me. Maybe you Cocoa masters out there can shed light on this.


#2

That doesn’t make any sense at all - it’s effectively the same code. There must be some other factor involved…


#3

When I do nothing but change that one line of code and recompile, it switches the rollover bug on and off repeatably.

[edit]

OK. it doesn’t. That’s embarrassing. I thought I had verified this but I’ll chalk it up to confirmation bias. Here’s what really happens:

When I click on the plugin window, the rollovers are in the correct positions. When on the other hand Live has the focus, the rollovers are sent relative to Live’s main window. I’ll take this one up with Ableton.


#4

WTF!??

I’m not the world’s greatest expert on obj-C, but surely the fact that it’s a temporary value can’t make any semantic difference…!

Even if the locationInWindow method caused side-effects, the order in which the methods are called is still the same in both cases. It doesn’t make any sense!

I think that whoever wrote the obj-C compiler would be a better person to ask! Seriously, that must be a compiler bug, but it’s such a simple piece of code that it just doesn’t seem possible.

But anyway, thanks! I guess I’ll put your change into the codebase, with a suitably bemused comment next to it!


#5

No, no — no need for the change! my edit above means (and says?) that the difference is not the inconsequential change in the code I pointed out. The difference is whether my plugin window had focus or not. Apparently I was clicking on the plugin window only when I was looking for the bug to be fixed, and so it appeared to be fixed.

In short: sorry, my bad. Oh and Ableton’s.