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.

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.

Sorry, but I guess you misunderstood me. In the sample Petar attached the problem occurs. Start it and as soon as it's loaded, the hierarchy doesn't work properly. Uncheck the first subnode of the "All"-member and you'll see what I mean. In larger hierarchies the problems even seem to be worse. For example checking/unchecking a node doesn't check any of it's children.

Well, it seems that's a bug. I have attached a modified version of MainWindow.xaml.cs of Petar's sample where is used an extended version of XmlaDataSource that let's you to create an empty filter view model. Look at CreateEmptyFilterViewModel method where you can see the commented line of code which loads the root level (that's the way XmlaDataSource works) you don't need now because you're going to load the whole hierarchy. 

I guess we will fix that for the upcoming SR.

Thanks.
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.