Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I'm using CSLA 4.3.13. I'm still relatively new to WPF and MVVM, so I could be doing somerthing wrong.
Anyway, I have a TabControl whose ContentControl is a UserControl. Within the UserControl I have an ItemsControl. The items have various controls that have PropertyStatus controls next to them. The PropertyStatus conttrols work fine. But if I switch to a different tab, I get a NullReferenceException, somewhere untraceable. If I take the PropertyStatus controls out, the exception goes away.
Has anyone else experienced this before? Anyone got any idea how to fix it? Of course I could just roll my own, but there's no guarantees I might not come up with the same problem, so I thought I'd ask.
Dan
I found a good workaround. I'm using an attached behavior from http://www.codeproject.com/Articles/362940/Persist-the-Visual-Tree-when-switching-tabs-in-the. It persists the visual tree for each tab item, and eliminates the exception. It also appears to fix the other little issues I was having.
Are you able to reproduce the bahavior in a small sample project? As that would be a good starting pointo the verify/debug PropertyStatus.
I did several bugfixes last year on PropertyStatus and tabs is a PITA. Tabs do NOT load controls for all pages - rather loads when required and this means that the "invisible", nonvisited tab pages (read controls) are not in the VisualTree.
Jonny Bekkum, Norway CslaContrib Coordinator
Thanks for the reply. No, I haven't tried to narrow it down to a simple solution. My guess was that it was related to exactly what you mentioned about TabControls and the visual tree. I was hoping someone knew of a quick fix, but otherwise, I didn't want to get bogged down debugging this. I'm so far behind on this project as it is, because I've been side-tracked by so many issues, and I promised myself not to let it happen again. :) We'll see how that goes.
With respect to your experiences with TabControls, I'd like to ask you a question. Not only do I have this PropertyStatus issue, but other oddities keep cropping up when switching from one tab to another. I'm beginning to wonder if I should scrap the TabControl and roll my own. For instance, I could have each tab page be some sort of container that all end up in the same grid cell, then collapsing all containers except the active one, etc. This would probably require some codebehind, but it's for a good cause. Do you think this would be a good idea? I'm worried I might end up wasting more precious time with these kinds of TabControl issues.
I'd love to hear your opinion on this. Thanks.
I've experienced this with WinForms (not CSLA project).
I found that one thing I ended up doing in this project was to iterate through the collection of tabs, SetFocus on each (something like that) - to cause them to all generate their controls right at the beginning. This was quite a long time ago, but that's the sort of thing I ended up needing to do.
Your workaround is indeed the sort of thing you need to do. We had exact same problem with a Infragistics tab control which inherits from the MS one.
WPF loads controls into the visual tree when they appear on the screen (sometimes you might be able to force them), but this can cause binding and validation issues. It's done for performance reasons apparently.
"Apparently". That made me smile!
FYI, I finally had to give up on the PropertyStatus control within the TabControl. I came across another situation where it threw a NullReferenceException. This time, it happend while removing an item from an ItemsControl (in a TabControl). It would have been nice if the PropertyStatus control implemented the try/catch/forget pattern, like most other things that cause binding issues. But whatever. You can't have everything, I guess.