We had this strange bug reported to us, and after looking into it a bit I was able to reproduce it just using the JUCE demo app, and it appears to be a core issue in JUCE's mouse handling. This issue does NOT occur in JUCE 1.52, but it happens in JUCE 3. I'm on Win 7, but I believe it happens on Win 8 too. Here are the repro steps:
- Launch the JUCE demo app and bring up Tabs & Widgets/Sliders. Note that the far left slider is one that jumps immediately upon clicking.
- Launch Notepad, and ctrl-O to bring up the system file open dialog. Now this is the tricky part. Navigate to a folder where there is a text file that you can open in notepad, then position the file dialog such that when you click on that file's icon, it is directly over the JUCE demo far left slider. Now double-click on the file icon. This opens the file in Notepad, but it ALSO causes the slider to jump to the location where you just clicked! It does NOT activate the JUCE demo window.
The problem is our app is a mixer controlling an audio device, so if you happen to have that file dialog positioned just right, you could accidentally crank your monitors to max volume!
Looking into in the debugger, here's the stack trace right after double-clicking in the file open dialog:
[URL=http://s168.photobucket.com/user/jwintermyre/media/Misc/Screen%20Shot%202015-12-23%20at%207.41.43%20PM.png.html][IMG]http://i168.photobucket.com/albums/u164/jwintermyre/Misc/Screen%20Shot%202015-12-23%20at%207.41.43%20PM.png[/IMG][/URL]
The windowProc is getting called with the message WM_MOUSEMOVE. This seems fine, but then MouseInputSourceInternal::setButtons() ends up generating a mouse DOWN event because at this point the modifiers seem to indicate that the mouse button is down. I finally tracked that down to this... in juce_win32_Windowing.cpp in HWNDComponentPeer::doMouseMove(), there is this:
void doMouseMove (Point<int> position)
{
if (! isMouseOver)
{
isMouseOver = true;
ModifierKeys::getCurrentModifiersRealtime(); // (This avoids a rare stuck-button problem when focus is lost unexpectedly)
updateKeyModifiers();
...
If I comment out the call to ModifierKeys::getCurrentModifiersRealtime(), that fixes the problem. Question is, what is the issue that was added for in the first place? Is there a better way to address this? I don't want to break something else with this fix.
Hopefully this hasn't already been addressed in the forum; I did a search and didn't find anything. Closest thing was this:
http://www.juce.com/forum/topic/146-151-dnd-issue