I'm looking for a way for the pivot control (respectively the OlapViewModel) to preload all members of a hierarchy. I've just written my own function that loops recursively through all members and calls the OlapViewModel's "FillMembers"-function, but that takes way too long for larger hierarchies.
Is there maybe a built-in functionality to let the class preload all the members?
BR,
Tristan
Btw:
- I'm also looking for a way to preload all availible FilterMembers in the related FilterViewModel
- How to trigger the "OK" Button from within the viewmodel. It uses the Commanding.Command OK event .
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.
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.
Thank you very much for your quick result! In my example I want to write something like a "plug-in" for the filter control so I can only use the datasource that is already used by the control. Can you estimate when this fix will be included in a SR?
BR! Tris
There was a SR released last week so I thinkg the next SR would be released after 3-4 weeks from now.
Best regards.Plamen.
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.
Drag a three level deep hierarchy ("All" + 2 levels) on your columns and call it's "AttachToProvider"-method. Expand the "All" member, uncheck one of it's children and after unchecking it expand it. You'll see that the node is uncheck but all it's submembers are still selected.
Tris
Hello Tris,
No, I'm not actually aware of it. It would be great if you give us some details about that.
Even with the supplied bugfix the hierarchies logic is still broken. Are you aware of this? Or should I try to describe the problem to you?