Good to hear it was painless. It goes to show that I should obviously defer to Greg's suggestions more often :)
I see you are calling treeView.getParent().repaint(); Does the parent need to be repainted, or could you get away with just repainting the TreeView? Also, bear in mind that there are multiple repaint methods, including the following two which *might* help to optimise repainting. http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/Component.html#repaint(org.apache.pivot.wtk.Bounds, boolean) http://pivot.apache.org/2.0/docs/api/org/apache/pivot/wtk/Component.html#repaint(int, int, int, int, boolean) Chris On 20 June 2011 19:53, Edvin Syse <[email protected]> wrote: > Sorry, there was a bug in it, fix attached :) > > Den 20.06.2011 14:51, skrev Edvin Syse: > > Den 17.06.2011 16:29, skrev Greg Brown: >> >>> Ahh, I hadn't considered the mouse blocking side of things, which is >>>> certainly desirable in some scenarios. In this particular case, I think it >>>> would be unwanted as the ActivityIndicator would be shown to the user while >>>> a TreeBranch is being populated via a potentially long running Task. >>>> Leaving the mouse enabled means that the user is free to do other things. >>>> >>> That's true. But I still think a custom node renderer would be the >>> easiest way to accomplish what Edvin is trying to do. :-) >>> >> You are oh so right :) It was super easy, I just did a quick test, and it >> works perfectly, even with multiple busy nodes simultaneously.Before I load >> data in a background task I do: >> >> nodeRenderer.setBusyNode(node) >> >> And remove the busy node after the loading task has completed >> (removeBusyNode(node)). Attached is my rudimentary implementation, will >> refactor it now that I see it is working :) >> >> -- Edvin >> >> >>
