Hello, 

I have been looking into your requirement and there is no built-in functionality that does that, however here is another custom approach that you can try out. I have put it in a small sample project for you (Pivot_Analysis.zip)  and in order to preload the members a FilterViewModel is manually created in code and its LoadMemebersAsynv method is used before being added to the Rows collection. If you want I can also submit a new Product Idea on your behalf so that such functionality may appear in a future volume release of ours. 

Please let me know if you require any further assistance on the matter.

Hey Petar,

Thank you for your reply. Your approach looks pretty similar to mine, excapt that you are using a FilterViewMode and I'm using the OlapViewModels Members directly. The problem is that expanding only one member takes about 0.25 seconds (in both our samples). So preloading a hierarchy with many thousand of nodes takes way too long! If the control built the whole hierarchy from one query, it could be done in a few seconds!

Additionally, I noticed that loading members that have already been loaded takes the same time! Isn't the control caching members it already needed to load?

Hello Tris,

Could you specify the library version you have used?

For the sample IDataProvider.LoadMembersAsync(ICube, IHierarchy) is used as it loads the whole hierarchy as make only one call to the server. When you have LoadFilterMembersCompleted fired with e.UserState of type IHierarchy that means the whole filter members’ hierarchy of IFIlterViewModel is already loaded. After this point expanding a filter member should not make further calls to the server.

Regards.
Plamen

Hey Plamen,

I'm using the latest version of the control (12.1). And you are right, I've got it wrong: the LoadMembersAsync method actually loads all the hierarchy's members and I can use them the way I want. But now there seems to be another annoying issue. The ViewModels's AttachToProvider-method seems to break the hierarchical strucure. Run Petar's solution and wait until the preloaded hierarchy is added to the rows. Now uncheck the first city in the filter and you'll see that the "All"-member doesn't get the value "null" set - it is still checked!

Hi,

I guess that's because you have set IFilterMember.IsSelected, however that property is bound to UI only and you have to call CommitChanges() of filter view model in order to get those changes into account. If you want to modify "the real" value you have to set IFilterMember.FilterSource.IsSelected and then you don't need to call CommitChanges().

Let me know if that works for you.

Plamen.

Hi Tris,

The next SR would be at some point in the next 2 weeks.

Plamen.

Are there any news yet? How long will it take to fix this bug?

You are right - I cannot reproduce the behavior in your example. I'll write a small sample application that will show you my problem.

It's supposed you need to call AttachToProvider only when you do anything with the provider like calling LoadMembersAsync(IHierarchy). That makes possible for filter view model to be aware about that call and can get the delivered members. You need never call AttachToProvider when you do drag drop.

Regards.
Plamen.