Magnifier Component lost mouse clicks?


#1

I have a problem that can be repeated with jucer: when zoomed down (larger viewport, zoomed down to see more) then most mouse clicks seem to be lost.

On Mac, if that makes a difference.

Bruce


#2

OK, some more info. The distance from component origin makes a difference. The further away the click is from 0,0, the less likely it is to be respected (also applies to mousewheel etc.)

If zoom factor gets much less than 0.5, almost no clicks are detected.

I can only assume that the mouse coordinates are being in correctly filtered as ‘outside’ the component, even when they’re inside the zoomed component. Can’t see where yet.

There’s also a fair amount of snail trails etc again - Jules, we solved 90% of this before by expanding the dirty region 2 or so pixels.

Bruce


#3

Traced as far as handleWheel in MouseInputSource.cpp, where: Component* current = getComponentUnderMouse();

Returns 0. Not sure if that’s because I’m in the debugger, or that’s the problem. Can’t see where coordinates are going wrong, but the first mouse action is being caught and operation on it starts - somehow it just doesn’t finish if the point is too ‘far’ into a zoomed view.

Bruce


#4

Ok, I see what’s going on there - the whole design of the magnifier just doesn’t fit with the new mouseinputsource classes… Hmm. Bit of a tricky one to fix, but I’ll take a look.


#5

Any clues? Maybe a way to revert to the older classes?

I presume the new classes pre-empt some multi-touch classes in some way?

The odd thing is that the click/drag has the correct coordinates ‘most’ of the way down through the callstack, then implodes.

Bruce


#6

It’s just a side-effect of my new MouseInputSource classes - previously, the ComponentPeers handled the events, so the magnifier could catch and redirect them properly, but now the mouseinputsources do it, they don’t take this stuff into account when they decide where to send the events. I’ll be looking at this shortly, so will sort something out.


#7

Any progress on this?


#8

Sorry, I’ve not had a look at it yet. Haven’t forgotten though!


#9

great thanks! It’s a really nice (and clever) little feature, and I am considering using it in a couple of my apps which are “bitmap” based GUIs for some mobile device support… so in fact the main windows content component would be wrapped in one of these guys.

As a side, the only serious problem I’ve encountered is the aforementioned mouse events (further from 0x0) when using fractional scaling, but otherwise works nicely and efficiently. Other tweaks I might suggest are things like menus; so when a menu calls showAt(componentx) for example, the coordinates returned from the component are scaled accordingly. Sounds trivial to me, but I imagine it’s not :wink: I also have some widgets which attempt to register keylisteners with the main window (via findparentcomponentofclass(documentwindow) or gettoplevelwindow, I forget), but IIRC the search up the hierarchy failed at the magnifier component, presumably because it’s a toplevelwindow itself… might be nice if the magnifier handled those kinds of requests “transparently”.

Anyway, thanks again :slight_smile:


#10

er, the keylistener thing is easy enough to work around, but I looked into this briefly and, it appears to fail in the texteditor components themselves when performing the command… didn’t look much further than that, but I’m guessing the scaling wreaks havoc on the caret/position/etc.


#11

Thanks very much for fixing this… it’s special! :wink: (Just merged the tip into my 1.50 base…) I modified it a bit to handle keylisteners and all, and added custom classes for “MagnifiedTextEditors” with “fake carets”… hacky approach I suppose, but not the first time I’ve done that particular hack for some API or another and I needed a quick fix for my purposes. Anyway, nice work :slight_smile: