Mouseclicks passing through components...?


#1

Hi there,

I use non-opaque components, and for some unknown reason, mouseclicks sometimes (but not always) pass straight through them. My top level window is also non-opaque, and the result is that my application suddenly lose focus to the application behind it - even though I clicked a component in my app! It is quite annoying. I have tried setting a component opaque (setOpaque(true)) and when I do, no mouse clicks fall through it…

Any thoughts?

  • A

#2

Well, I think the OS will allow through any clicks on transparent pixels. Not sure if there’s anything that could be done about that, TBH…


#3

Thanks for your reply Jules. Here’s a little follow up - I didn’t want to put too much into the mix before, in case it was a trivial matter. Here goes:

  • The pixels I click when the events fall through vary in opacity. They are never completely transparent though. If the OS “send” mouseclicks to not entirely transparent (as your reply suggests…?), then how come it is not possible to catch these and make the decision myself? That should be what the hitTest is for…?

  • The problem varies with activity. I am doing a wave editor, and in one part of the program, the problem is only there when the audio is playing back. Most strange, but it may be some subtle threading issue, since the playback sets up an audio callback.

That’s what I can think of so far, without posting kiloes of code here :wink:

  • A

#4

Oh, sorry - did you mean that these are transparent components in a normal window? I thought you meant that you were using transparent top-level windows.

If these are just normal juce comps then yes, it’s all controllable by your hitTest method, not by the content of what you’re drawing. That code is rock-solid so if you’re getting unpredictable behaviour, it must be down to something else that’s going wrong in your app.


#5

The Toplevel window is transparent too. What really baffles me is the appearent randomness to the clicks that fall through. And then of course the fact that when the application is not actively playing the sound back, no clicks fall through. Ever.

I have tried this and that, and I definetly believe you when you say “rock solid”. Oh well, I was writing on the chance that you had seen or heard of this kind of problem, and could say something like “if you’re doing then you are asking for it…”.

  • A

#6

Right, well what I mean is that the lightweight component hit-testing is rock-solid, but when your top-level window is transparent, you’re at the mercy of the operating system as to whether the click gets sent to your app at all, and mac/windows are probably different in the way that they decide this.

Strange about the audio, though I bet it’s not actually to do with that. Perhaps it’s related to whether the window has focus?

The first thing I’d try here would be to fill the background of your window with a solid colour, and see if that makes a difference. If so, then we know it’s the OS redirecting the clicks based on the pixel colour.


#7

Yes, that sounds like a good idea - to be sure: keep the toplevel window setOpaque(true) 'ed, but filling it with a solid colour in the paint method…

I have wondered about the focus/activity too, but am pretty sure that no focus/activity shift is going on. I have no calls to explicitly do this, so unless Juce does it when updating components (repainting, moving, resizing, …)

Thanks for your help so far… Juce is wonderful, and I am having great fun with it!

BTW, suggestions for addition - where do they go? Specifically, I would like (nay, love) a setSampleRate alongside the getCurrentSampleRate in AudioIODevice…

  • A

#8

no - keep it transparent, and just tweak your paint method.

Just post them in here somewhere, I try to read all the forum posts.

As for setSampleRate… well, you can already change the sample rate with one line of code by reopening it, so I’m not sure there’s much point in having a wrapper method to do that? I’d rather not clutter the class up if I can help it.


#9

Heh, sorry about that - I obviously meant (false), wanting the window to be “truly transparent” :wink:

Oh… Er… Okay! I did not think of that. Thanks! I will let you know of my findings regarding mouseclicks.

  • A

#10

After a bit of investigation, it seems that the crucial difference is the setOpaque(false) 'ness that is problematic. When the toplevel window is opaque, no mouseclicks fall through, no matter how much I bombard it. The same goes for a component in modal state.

When the top level window and the modal component are non-opaque, it happens that mouseclicks fall through them - regardless of the painted content or child components.

An interesting finding though, is that when a portion of the window is completely transparent (i.e. nothing is drawn, and likewise for any child components in front), the clicks fall through every time. It seems like the more transparent, the greater possibility of mouseclicks falling through. It is not directly proportional though, because when the window has a completely opaque background (drawn, not setOpaque(true)'ed), then it still happens that clicks fall through.

What do you make of this…?

  • A

#11

Well, there are only really two ways the OS can do it - it can either require a pixel to have 0 alpha before the mouse-click goes through, or it can have a threshold, which you’d probably expect to be 127.

I’ve just been having a look through the mac documentation but actually can’t find anything about this. It must be in there somewhere…


#12

If that’s the case, I will be slightly annoyed. Either that, or it must be possible to set this threshold value per window…? If not, I will not be able to make the liquidy windows I so sorely need. Or want, maybe.

[quote=“jules”]
I’ve just been having a look through the mac documentation but actually can’t find anything about this. It must be in there somewhere…[/quote]
Thanks so far… I will poke around too, and if I find a solution I will let you know.

  • A