Tree repainting problem when openness changes

MacOSX and iOS
1

Hi,

On my mac (MacOS X 10.4, Xcode 2.41, Juce 1.50), sub-items are not drawn when I open a tree item. In order to be drawn, I need to perform another operation on the tree (either passing the mouse over the new sub-items, or changing the selected item, or resizing the tree, …).

I performed some tests and it seems that TreeView::itemsChanged() needs to be called a second time after opening an item, in order to have the sub-items drawn. The problems seems to be related to the async-update.

I do not exactly understand why updates need to be async, and I naively tried the following modification:

void TreeView::itemsChanged() throw()
{
    needsRecalculating = true;
    repaint();
#ifdef JUCE_MAC
    handleAsyncUpdate();
#else
    triggerAsyncUpdate();
#endif // JUCE_MAC
}

That solves my problem ! However, my fix is very ugly …

Has anyone the same kind of problems ? How could this be solved in a clean way ?

Francis.

2

I don’t understand why it’d make any difference whether the update is performed immediately or later (?)… Surely either way, your new nodes are in place and the routine will run.

And why would it be different on the mac?? This is a very odd one!

3

Hi ! Have a look there too :wink: :
http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=2890&highlight=treeview+bug

4

Ok, I’ve figured it out, I think. It’s pretty obscure.

The tree relies on the fact that if you call repaint() during a paint() callback, it’ll cause another repaint to be triggered. But a few quick tests show that on the mac, any calls to repaint() during a paint() method were getting thrown away.

I’ve checked in a fix that gives the mac windowing code the correct behaviour, and hopefully that should sort out the treeview!

5

Not totally related but is there two kind of commit in git ?
at
http://sourceforge.net/projects/juce/develop
it says last commit on 2009-09-19
which obviously is not the right time

6

Weird… if I do a ‘git log’ all the details are correct, but sourceforge seems to be screwing up its list… Any git experts know what might be wrong?

7

It’s correct if you look at this list:
http://juce.git.sourceforge.net/git/gitweb.cgi?p=juce/juce;a=log

I guess sourceforge is just being a bit flakey.