Hi there,
I implemented the XamDockManger with my ViewModel, as described in one of your Blogs and it works like a charm (http://ko.infragistics.com/community/blogs/blagunas/archive/2013/09/24/xamdockmanager-data-binding-contentpanes-with-mvvm.aspx).
But now I’m facing a problem when I want so save and reload the current layout, because after loading the layout the TagGroupPane with its behavior will not be recreated like I defined it before. This mean that no new added Items to my ItemsSource will be added to the XamDockManager anymore.
I think this happens because the load-event takes my existing panes and add them to a new TagGroupPane, because I haven’t set a Name to my TagGroupPane w/ behavior. But as soon I add a Name to one of my DocumentPane, SplitPane or TagGroup I get an exception that “An item with the same key has already been added” while trying to load the layout.
But as far as I can see the above blog-example shows a way where only one TagGroupPane have and should have the ItemSourceBehaivor, otherwise every TagGroupPane will add the new Item to his own panes.
So now I’m trying to archive an implementation of the XamDockManger with DataBinding its ContentPane to one main TagGroupPane and the ability to save and load my configuration and still have the CollectionChanged handling after I did my loading.
I created a small example and some use-cases:
Rearrange the panes, add new => new tab is shown
Rearrange the panes, save layout, load layout, add new => new tab is not shown
Rearrange the panes, save layout, add new, load layout, add new => old TagGroupPane w/behavior will be “added” and all other (new and old) panes will be also displayed in it + adding new panes still works
Rearrange the panes, save layout, restart app, add new, load layout => old TagGroupPane w/behavior will be “added” and only the new panes will be displayed in it + adding new panes still works
BR
Andreas Hensel
Hi Andreas,
The main reason why the behavior stops working after a LoadLayout is because the TabGroupPane was replaced. Since the behavior is still on the old one and has not been moved to the new TabGroupPane, the add button doesn't show a new pane. I thought maybe you could give the TabGroupPane a name so that it would be reused by the XamDockManager but it looks like this just causes another exception based on the pane location. I'm currently looking into this to see if I can get it working. I'll let you know once I have something.
Hi Rob,
Thanks for your quick response and looking into it. And it’s good to know that my first assumption of this behavior was sort of right.
At this point I’m also quite open for a code-behind based solution :)
Andreas
That's great! We fixed this issue in the latest SR so I'm glad you tried it out and can confirm that. I'll pass on your thanks to our development team. :)
I just want to inform you that I tested the new March 2016 Service-Release (20152.2100) for 15.2 and as far as I can see my problem is fixed and I can implement my required behavior.
I also edited my example a little, if someone needs it.
Thank you for your help and creating the issue and also thanks to the person who fixed it.
I am also very interested seeing this implementation in the sample as well as the fix for the bug report. I use the same method for binding in my MVVM project when using the xamDockManager and Save/LoadLayout.
Thanks,
//Amanda
Edit: I have been trying to get the code-behind workaround suggested by Rob working in my application. I can see where it does reattach the behavior, however I still have problems when I have used the LoadLayout method it will not allow new tabs to be added to the DocumentContentHost. I have to restart my application and the new tabs will show up. Any help with this would be appreciated. I would also like to be added to the dev issue to notify me when a fix to the control is available. I may end up making this a support request as well, but it would help a lot just to see the code-behind workaround in the sample provided by the OP.
I was wondering if you could give me your implementation of your code-behind solution.
sorry for my late response but Christmas came early last year for me. Thanks again for looking into my problem and finding the cause for this behavior, I’m looking forward to implement the soon new service release.
In the meantime I tried to use your code-behind snippet but I’m not 100% sure how to implement it now, could you update my example with your solution?