Sorry - I ran the code, and made the following comment, but didn't yet post until I could do a little more analysis of the original issue:

Thanks for the updated examples - it turns out this is a slightly different bug, but can be fixed fairly simply - some bookkeeping needed to make update work correctly is incorrectly checking if that item is visible.

The original issue is a little more complex - the bug is roughly that the TreeGrid only expects StoreDataChangedEvents to mean that new items were loaded, not that existing items should be cleared. Removing this assumption mostly means that a few items should be removed before inserting the new, but some state details like expand/collapsed might be lost. This isn't necessarily a bad thing, since data changed implies that items were completely replaced, as opposed to having been updated.

The more recent bug fix will be committed soon, but the more complex issue will require additional testing/verification before I'll be confident enough in risking pushing it out as 'correct'.

Thanks for the reminder, and again, my apologies on the delay in getting back to you.

Due to our deadline we had to remove the functions in our software in the situations where the above mentioned errors occurred... Our customer is 'really' not happy... When and how are these bug-fixes committed? Any timeline?

There's a lot of discussion going on over here about our future use of Sencha GXT (or going plain GWT for example). Do we really need premium support for bug fixes within one month? (The so called Emergency Bug Fixes). Do we get this for bug fixes within one month with premium support?

I have the fix for the update() issue in our code review process - once it is approved and passes a build (with associated tests) it will be present in SVN and our nightly builds, both available to support subscribers right away, and shortly thereafter in a support release. The other issue is a little trickier, and I haven't yet nailed down a proper fix (just several ways to work around the issue, which may either introduce new issues, or leave other cases unsolved) that logically solves the problem. That said, using replaceChildren in your case seems overkill, as previously discussed, and additionally, I provided a workaround to allow such code to work.

This bug has been a very big time sink already - with the initial posts I tried to reproduce, but until there was enough details I was unable to do so. I understand that data widget bugs can be extremely hard to debug, so I personally try to focus on those as high priority issues, and try to provide workarounds as soon as possible, which I think I've been able to do in this case. I hope to have a similar workaround for the update bug in the near future.

While we GXT developers also provide support for the product, I'm not an expert in the specific details of support offerings. We highly prioritize issues that are filed in the support portal and try to work closely with those customers to reproduce the issues, either in a broken out use case or over a screen-sharing session. Beyond that, you should probably email someone on the support or sales team to get specific details.

Your username does not have the 'support' tag under it, which may mean that your support account isn't attached to your forum account, or that you don't have a support account. If your forum account is linked to a support account, you will also have access to a premium help forum which gets faster answers than the community forums (which are answered by the community, not only by team members).

Both issues (data changed via TreeStore.replaceAll and update via TreeStore.update) have been fixed in SVN, and will be available in the next release.

Two workarounds for the update bug:
* Declare a equals method for your model object so that the old and the new models are treated as the same. This is the main thing causing this issue, that ListStore.indexOf is being used to compare objects instead of only comparing by key.
* Alternatively, modify TreeGrid.onUpdate to compare by key instead of using indexOf: