Good catch. It should be sufficient to simply repaint the node bounds on the TreeView itself.
On Jun 20, 2011, at 9:11 AM, Chris Bartlett wrote: > 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 > > >
