Plugin redraws after setBounds(), but not direct calls to repaint()


#1

I have a plugin-based GUI that uses custom DLLs. One of the plugins has a component that needs to be animated. I'm using a Timer to repeatedly call "repaint()," but the component never gets redrawn unless I change its size or location by invoking setBounds(). The component works fine when it's part of the host application. In plugin-mode, all of its behaviors other than repaint() work exactly as expected.

Has anyone experienced this before? Am I missing something fundamental about the way calls to repaint() should be handled by plugins?


#2

My first guess would be that you're calling repaint on the wrong component.

It's not impossible that some weird host/windowing issue could break it, but if it did, then nothing would ever redraw, e.g. buttons, sliders and pretty much every kind of component relies on repaint().


#3

Hmm...the component's method that contains "repaint()" is definitely being called, but the painting never happens.

What's even stranger is that when the component calls setBounds() on itself, it doesn't get repainted. But when the window changes size, everything works as expected.


#4

Well, I've never seen anything like that, and the fact that you said you're "using custom DLLs" sounds suspicious to me. I can't really help you debug it, but let me know if you find anything fishy that seems to be my fault.


#5

I solved this by having the animation callbacks go to the plugin's parent component, which is part of the host application. Calling repaint() on the parent automatically redraws its children, but for some reason the childrens' repaint() requests are ignored.

I'm not sure how general this solution is, but everything seems to work fine now.


#6

I think you're misunderstanding that - any C++ object that you can call repaint() on is definitely part of the plugin's codebase, not the host's.


#7

Sorry if I wasn't clear—the host is a Juce application that I wrote.