Juce Demo: Assertion failure in -[NSEvent deviceDeltaX]

I am receiving the message

…when trying to scroll with the mouse wheel in the “Table Components” section of the juce demo on on OSX 10.6.8.

=====================================

Now I’m not sure if this is related (or just due to my crummy coding), but In my own application I also get the message

…when changing the colour of a text button that is a custom component in a Table Component cell. It occurs somewhere in . .

void TextButton::colourChanged() { repaint(); }

…and I narrowed it down to happening somewhere in here (I am using a mmlock from the audio thread - it only occurs when I do this and it only happens on the first time a button paint method is called from the audio thread)

[code]void Component::internalRepaint (int x, int y, int w, int h)
{
// if component methods are being called from threads other than the message
// thread, you’ll need to use a MessageManagerLock object to make sure it’s thread-safe.
CHECK_MESSAGE_MANAGER_IS_LOCKED

if (x < 0)
{
    w += x;
    x = 0;
}

if (x + w > getWidth())
    w = getWidth() - x;

if (w > 0)
{
    if (y < 0)
    {
        h += y;
        y = 0;
    }

    if (y + h > getHeight())
        h = getHeight() - y;

    if (h > 0)
    {
        if (parentComponent != nullptr)
        {
            if (parentComponent->flags.visibleFlag)
            {
                if (affineTransform == nullptr)
                {
                    parentComponent->internalRepaint (x + getX(), y + getY(), w, h);
                }
                else
                {
                    const Rectangle<int> r (ComponentHelpers::convertToParentSpace (*this, Rectangle<int> (x, y, w, h)));
                    parentComponent->internalRepaint (r.getX(), r.getY(), r.getWidth(), r.getHeight());
                }
            }
        }
        else if (flags.hasHeavyweightPeerFlag)
        {
            ComponentPeer* const peer = getPeer();

            if (peer != nullptr)
                peer->repaint (Rectangle<int> (x, y, w, h));
        }
    }
}

}[/code]

Thanks for looking. I’ll be happy to provide more info if asked.

FWIW, I’m building with the tip of “Modules” and don’t get an assertion on 10.5.8, 10.6.8, or 10.7. I also have an app that uses the Table component, and don’t get an assertion with it either.

That’s on a Mac Mini and a MacBook pro. As far as your repaint problem, I’m not sure I understand, are you invoking something to cause the repaint from your audio thread directly, or just noticed that the problem coincides with MM Lock from another thread?

Ah. I have not checked the modules brach out yet. Perhaps i should take the plunge.

I am invoking the repaint from the audio thread directly. Each row in my table represents an object with its own audio callback. I was running into all kinds of troubles using change broadcasters in components within the table component, so I gave up and made the pointer to the component containing the button available to the object with the audio callback and vice versa.

Sorry if this is unintelligible. I am half asleep. Thanks for the response. I will check back tomorrow.

FWIW, when I did a dynamic content table, I used postCommandMessage from worker threads. Then put some logic in the component message handler containing my table to minimize redundant repaints.

From a quick experiment, it seemed to me that the Table control was being smart about reusing allocated components (that is, it had components representing rows you could see, not components mapped 1:1 to actual table contents, so I wanted to always use the table’s built in mechanism for updating the state of custom controls, since scrolling could break the relationship between component and underlying element.

I also didn’t want to deal with problems with threads accessing controls after their end of life. I don’t know if it is related, but I haven’t had any crash problems on either Windows or Mac working that way.

As far as the scroll, it might be the branch, or it could just be something different about your setup I’m not running into (that’s why I mentioned what platforms I was using).

Good luck!

If you’re using an old-fashioned clicky mouse-wheel (like the one I use), then the OSX event classes will spit out internal exceptions when you try to access the modern mouse-wheel delta values. My code just catches these exceptions and ignores them, but the OSX code prints a debug trace about it, which you can ignore.

I am

Great. Good to know. Thanks Jules.

=========================================================

Thanks. I never noticed postCommandMessage before. So I can safely call this member function via a pointer to a deleted object, without the program crashing due to an access violation?

So in handleCommandMessage you did some kind of selective repaint, only updating custom components that were related to the command Id?

[quote=“jfitzpat”]From a quick experiment, it seemed to me that the Table control was being smart about reusing allocated components (that is, it had components representing rows you could see, not components mapped 1:1 to actual table contents, so I wanted to always use the table’s built in mechanism for updating the state of custom controls, since scrolling could break the relationship between component and underlying element.

I also didn’t want to deal with problems with threads accessing controls after their end of life. I don’t know if it is related, but I haven’t had any crash problems on either Windows or Mac working that way.[/quote]

It almost certainly is related to my problems (EXC_BAD_ACCESS popping up at strange times). I see that my data model persists in the background, but the graphical components representing it may vanish at any moment, or be recreated at a different memory address? Perhaps I am not understanding the table’s built in mechanism for updating the state of custom controls as well as I should. Thanks again jfitzpat. Your input is helping me a lot.