JUCEDemo Assert fail in Slider::mouseDrag


#1

Just cloned the latest tip from git (Introjucer reports 1.54.27) and did a full Win32 Debug build of JUCE under VS 2010 on my 64-bit Win 7 machine. Clean build, no problems. Built the Release version as well, no problems. Then I built the JuceDemo (Debug) and again no problems.

Started the demo (under the debugger), changed the look and feel back and forth, Alt-tabbed to another window and noticed the “J” icon on the task tray. Clicked it, didn’t seem to have an effect, right-clicked and saw it was the JuceDemo. Clicked back on the demo window and either right then or very soon thereafter got the assert failure, Slider::mouseDrag(), line 1381.

Full traceback info below, but I should mention that sliderBeingDragged has a value of -1. Also, valueWhenLastDragged has a value of -180 so it hasn’t been set either.

I don’t believe I actually dragged any sliders at any time. I had only been running the demo for about a minute and had tabbed away to another app so I hardly had time. I had checked one of the boxes to see what it looked like, then changed the look and feel to the older style and back again.

Note that code structure is like:

    if (sliderBeingDragged == 0)
      ...
    else if (sliderBeingDragged == 1)
      ...
    else
    {
        jassert (sliderBeingDragged == 2);
        ...

Since sliderBeingDragged is still -1, it asserts. I suspect there just needs to be a check for -1 here and perhaps this code doesn’t even need to get called. The root trigger for all this is the call several frames back:
if (buttonState.isAnyMouseButtonDown() == newButtonState.isAnyMouseButtonDown())

Here is the full traceback:

JuceDemo.exe!juce::Slider::mouseDrag(const juce::MouseEvent & e={…}) Line 1381 + 0x64 bytes C++
JuceDemo.exe!juce::Component::internalMouseDrag(juce::MouseInputSource & source={…}, const juce::Point & relativePos={…}, const juce::Time & time={…}) Line 2489 C++
JuceDemo.exe!juce::MouseInputSourceInternal::sendMouseDrag(juce::Component * const comp=0x0328bab8, const juce::Point & screenPos={…}, const juce::Time & time={…}) Line 128 + 0x39 bytes C++
JuceDemo.exe!juce::MouseInputSourceInternal::setScreenPos(const juce::Point & newScreenPos={…}, const juce::Time & time={…}, const bool forceUpdate=false) Line 254 + 0x37 bytes C++
JuceDemo.exe!juce::MouseInputSourceInternal::setButtons(const juce::Point & screenPos={…}, const juce::Time & time={…}, const juce::ModifierKeys & newButtonState={…}) Line 153 C++
JuceDemo.exe!juce::MouseInputSourceInternal::handleEvent(juce::ComponentPeer * const newPeer=0x032861e0, const juce::Point & positionWithinPeer={…}, const juce::Time & time={…}, const juce::ModifierKeys & newMods={…}) Line 288 + 0x14 bytes C++
JuceDemo.exe!juce::MouseInputSource::handleEvent(juce::ComponentPeer * peer=0x032861e0, const juce::Point & positionWithinPeer={…}, const int64 time=1318036947472, const juce::ModifierKeys & mods={…}) Line 537 + 0x48 bytes C++
JuceDemo.exe!juce::ComponentPeer::handleMouseEvent(const int touchIndex=0, const juce::Point & positionWithinPeer={…}, const juce::ModifierKeys & newMods={…}, const int64 time=1318036947472) Line 108 C++
JuceDemo.exe!juce::Win32ComponentPeer::doMouseEvent(const juce::Point & position={…}) Line 1381 C++
JuceDemo.exe!juce::Win32ComponentPeer::doMouseMove(const juce::Point & position={…}) Line 1462 C++
JuceDemo.exe!juce::Win32ComponentPeer::peerWindowProc(HWND
* h=0x00020c48, unsigned int message=512, unsigned int wParam=0, long lParam=37028183) Line 2024 + 0x32 bytes C++
JuceDemo.exe!juce::Win32ComponentPeer::windowProc(HWND
* h=0x00020c48, unsigned int message=512, unsigned int wParam=0, long lParam=37028183) Line 1956 + 0x18 bytes C++


#2

In the more recent modules branch, that assertion no longer exists, so I guess I’ve fixed whatever the problem was!


#3

[quote=“jules”]In the more recent modules branch, that assertion no longer exists, so I guess I’ve fixed whatever the problem was![/quote]That’s excellent to hear!

It does make me wonder however what I should be building against. The 1.53 release is starting to get a bit dated again (3.5 months old) which would be fine if JUCE wasn’t seeing active development, but the changes since then look pretty meaty to me… It’s kind of tempting to go with something more recent. I see lots of work merged back from that Modules branch; is that the more active tip? Or for someone who just needs something relatively bug-free, is 1.53 the way to go?


#4

The modules branch will become the next official release, but is still under development while I get it stable. Up to you which one you use in the meantime…


#5

[quote=“jules”]The modules branch will become the next official release, but is still under development while I get it stable. Up to you which one you use in the meantime…[/quote]Understood. Thanks for the quick response!