Dialog not respond to Touch event on Windows 10


We encountered a touch related problem on Windows 10: FileChooser (and other dialogs) not respond to Touch events (mouse is ok). We can reproduce this problem with JuceDemo.

In JuceDemo, go to Dialog Boxes, click Load File Browser button to open FileChooser dialog, then touch by finger on any button in it, seems like it does not receive any touch event. Use mouse can interact with FileChooser dialog w/o problem.

  • JUCE 4.2.4
  • Windows 10 64-bit Anniversary Update (10493)
  • Microsoft Surface Pro

Any suggestion?

We observed a strange behaviour, if mouse click on Load File Browser button to open FileChooser dialog, then the touch by finger operation works fine.

Touch Abnormal Steps

1. In JuceDemo > Dialog Boxes, Touch on Load File Browser button

  1. FileChooser dialog open up
  2. Touch on that dialog has no function

Touch Normal Steps

  1. In JuceDemo > Dialog Boxes, mouse click on Load File Browser button
  2. FileChooser dialog open up
  3. Touch on that dialog work just fine

Please check the develop branch. I think @ed95 may have fixed this a while back.

Tried develop branch at commit 15bed81, but the problem remains.

Another thing I noticed is that after dismiss the FileChooser dialog, there will have a Touch event on main window. Below is screencast of the the problem, what I did is:

  1. Touch on Load File Browser button to open FileChooser dialog.
  2. Touch on FileChooser dialog but it does not respond to touch
  3. Use mouse to dismiss FileChooser dialog, after this
  4. You can see there is a Touch event happening near the Load File Browser button.

Hi @sam,

Thank you for reporting this. In deed, we can reproduce this here at ROLI. I’m afraid however, that I’m having issues debugging this as the only touch screen we have available at the moment does not work very well with the Windows VM (it simply stops working after two or three touches). We have a Windows 10 laptop with a touch screen here at ROLI but it will take a few days until I can get hold of it.

I’ve put this bug into our internal bug tracker as a high priority bug and we will look at this as soon as possible.


Hi @fabian,

Thanks for reply. We too are digging deeper for this problem since it might affect our products in long run, if there is anything we can do to help solve this problem, feel free to let me know.

Another thing we noticed that normally, touch event on Windows is done by WM_INPUT message, we set breakpoint on the message loop and found that when problem occurred, there is no WM_INPUT message when focus window is FileChooser dialog.

We will update if anything new.

HI Fabian,

Please make sure to get a laptop that also has a digitizer. There are different problems with that. It works ok as a mouse replacement, but making a drawing application is currently impossible because of some weird delay after the initial mouseDown. Basically I get one mouseDown event and then only after a delay a quick succession of mouseDragged (with a surface book pen).

I’m pretty sure the touch problems come from windows touch to mouse conversion which confuses the juce button logic as it sees events twice. If I remember correctly there are ways in windows to turn of touch conversion on a per app basis. Maybe JUCE would need to support that for correct touch support.

Hi @fabian,

Just a quick note. I noticed several commit related to touch and did a test again on MS Surface, the problem remains.

We are working on a project that is Touch intensive and if we figure something out, will update to this thread.

Hi sam,

I’ve just pushed a fix for this to develop, hopefully it should be working now.


1 Like


Yes! I verified it on Surface Pro 3. It works now. Thank you!


I can confirm touch is fixed on my surface book. However, the change has broken pen in a bad way. I now get mouseDown events for the pen when it comes into proximity (~1 cm above the display). Before the change it was working correctly in that regard and would only produce a mouseDown once the pen actually touched the surface. We are also missing metadata for the pen - such as pressure, information about eraser mode (pen flipped), or even knowing the event comes from pen/touch or mouse. And I still get event delays once dragging starts - which seems to be a general problem for windows applications not properly configured for touch/pen.

This information is present in the windows structures but Juce doesn’t extract it as far as I can tell. Or is there a way to get the native event information without ugly hacks?

Bump. Pen support is completely broken on windows 10 since this touch fix. Are there any plans to fix that?

You already have a pressure field in MouseEvent. However currently WM_POINTER always leads to pressure = 0.0f. And I am getting two mousedowns, one when entering proximity of the screen and another one when the screen is touched. If pressure would work, I could at least work around this problem.

Oops and before I forget it. What’s also desperately needed is a way to tell where events come from. Mouse vs Touch vs Pen as well as knowning whether the pen is in eraser (=flipped) mode. Basically everything that was solved by that WM_POINTER api that’s now partially supported. The same mechanisms would also be needed for iOS with the iPad Pro and the Apple Pencil. Right now it seems impossible to create any kind of serious drawing application with Juce.

The 4.3.1 Changelog tells me “multiple issues with mouse/touch/pen” have been resolved on windows 10, but for me pen input is still completely broken as I described a few posts ago. Am I missing something? Am I the only person getting mouseDown calls when my surface pen enters proximity?

Hi Ed,

I’m facing the same issue in one of my application where I have no clue on how to fix it. Can you please put some light into it?

The issue is same, I have a modal dialog implementation (file browser) with custom message loop. Touch on this browser dialog works fine if I click on the button with mouse and the touch on the dialog. But if I open the dialog with a touch event, later on no touch inputs are receiving by the dialog.

Sorry for an off topic, please help.

So this is in an application not using JUCE?

This issue was fixed in JUCE by adding support for Windows’ pointer API which you can read about here. Also check out the native windowing code in JUCE here to see how it’s implemented.

We can’t really spend helping you fix non-JUCE code, but like Ed said, our code is all there for you to dig into if you want to see how it’s done.