Feature input request: WPF collections

Feature input request: WPF collections

Old forum URL: forums.lhotka.net/forums/t/6218.aspx


RockfordLhotka posted on Tuesday, January 20, 2009

One issue that has come up repeatedly over the past while is how collections work in WPF, especially now that WPF has a datagrid.

It turns out that the WPF binding infrastructure works so-so with a BindingList<T>. Actually it works fine, until you have a datagrid. The datagrid seems to make assumptions around the use of simpler list types, and doesn't really like BindingList<T> so much.

This poses a challenge for CSLA, because its collections are all based on BindingList<T>. This is a requirement for Windows Forms support, because Windows Forms data binding relies on BindingList<T> (or IBindingList) rather extensively.

There are no good solutions that I'm aware of. Microsoft has painted us into a corner, where you can really support WinForms or WPF, but not both at the same time. Which flies in the face of a primary CSLA goal - which is to enable the creation of UI-neutral business objects.

So here are the options as I see them:

  1. Use a compiler directive so you can build CSLA for Windows or WPF (which you'd have to do on both client and app server in a 3-tier model, because serialization requires the same inheritance structure for the types). When building for WPF, all collections would be based on ObservableCollection<T> instead of BindingList<T>.
  2. Add a new set of WPF-friendly collection base classes - basically WpfBusinessListBase, WpfNameValueListBase, etc. This would nearly double the maintenance work on my end, and would slow progress of CSLA into the future
  3. Drop support for Windows Forms as of CSLA .NET 4.0 - supporting WPF, Silverlight, ASP.NET, XML service and workflow interfaces, but not WinForms

If anyone has other suggestions I'm all ears.

I put number 1 first, because of the three poor choices, it seems like the least poor. It still leaves people building hybrid WinForms/WPF apps in a nasty spot, but does allow CSLA to function properly with WPF for people working entirely in that technology.

TAC replied on Tuesday, January 20, 2009

I don't see the 3rd option bring an option. Doing would force one of the following options...
- Update all WinForms to WPF - Many People will have too much legacy code and having them to rewrite all those screens is a big ask.
- Not use the latest version of CSLA - Could really stop the growth of CSLA
- Use two versions in the same program - would get quite confusing.

The first seems to be the best option although not ideal.

Does this problem only affect WPF or is it Silverlight as well?

Also could you provide a link to a post which provides more details on what the problem is exactly?

RockfordLhotka replied on Tuesday, January 20, 2009

The problem doesn’t affect Silverlight, because the CSLA .NET for Silverlight collections are based on a different base class. There is no BindingList<T> in Silverlight, because there’s no Windows Forms.

 

The primary issue is automated sorting. If you bind many types of list to the WPF datagrid they “automatically” sort. This doesn’t happen with an IBindingList list.

 

I say “automatically”, because WPF is actually doing a bit of magic to enable this functionality by providing a view over the list. If they see an IBindingList they don’t do their magic, because it would conflict with the DataTable, and possibly other IBindingList-based objects. Which means a BusinessListBase, or other CSLA collection, won’t automatically sort in the datagrid – leaving you to handle grid events to execute LINQ statements or something.

 

In other words, there are workarounds today.

 

But let’s face it. WPF/Silverlight are the future. WinForms is legacy technology. I think it is important that CSLA support the future, or it could become irrelevant, and so I want to find a solution that allows CSLA-based collections to act as first-class citizens in WPF.

 

And there’s a time constraint on this. WPF has had slow adoption due to a lack of tooling. But I think it is fair to expect decent tooling soon – Microsoft knows this is the issue blocking adoption. So I anticipate needing a good answer by Visual Studio 2010 and .NET 4.0 – more or less at the end of this year.

 

Which is why I started this thread now. Maybe someone knows of a better solution. Maybe someone has a clever idea. Or maybe we have to choose one of the options I listed above. In any case, now’s the time to figure out the direction so we all have months to deal with the consequences.

 

Rocky

rsbaker0 replied on Wednesday, January 21, 2009

I was going to naively ask if derivation from ObservableCollection<T> while also implementing IBindingList would be possible, but it sounds like WPF is explicitly testing for IBindingList and bypassing the sorting functionality based on what you are saying.

lukky replied on Wednesday, January 21, 2009

Rocky,

I think you're in a very tight spot. Damned if you do, damned if you don't.

While I understand that WinForms is a legacy technology in the eyes of many, it is still the platform of choice for a lot of new projects even today. You mentioned lack of WPF adoption, or at least slow adoption by the programmer community. I think this is a clear indication that WinForm is still extensively used. Remember that some customers still specifically ask for WinForms for new projects.

On the other hand, as you told me in another thread a few weeks back, those of us who haven't started to look at WPF should really think about it SOON, and I agree with that. As a side note, I just bought my first WPF book Wink [;)]

My personal concern is that if you drop WinForms support in 4.0, all of us still using it for new project are going to fell left behind if you should integrate new features in CSLA that don't really depend on WPF, but that would make life easier for WinForms people too. Would you eventually agree to backport those into CSLA 3.X ?

I'm sorry I don't have any cleaver answers to this dilema. I'm just an egg. One thing that comes to my mind though, is if you could somehow make UI support plugable into the framework. After all, one of the goal is to be UI agnostic, isn't it ? What I mean is that right now, you're using inheritance to do your magic. Would it be at all thinkable to use composition instead ?

In any case, I personally think it's too early to drop WinForms support.

Best regards.

rsbaker0 replied on Wednesday, January 21, 2009

RockfordLhotka:

The problem doesn’t affect Silverlight, because the CSLA .NET for Silverlight collections are based on a different base class. There is no BindingList<T> in Silverlight, because there’s no Windows Forms.

...

 

Interesting, because BindingList<T> is in the System.ComponentModel namespace, not the System.Windows.Forms namespace.

Does this mean that WPF is basically going it's own way as far as the previous support in .NET for building components? It looks to me like System.ComponentModel at least makes an attempt to be "WinForms agnostic", but I haven't looked at it closely enough to state this with certainty.

RockfordLhotka replied on Wednesday, January 21, 2009

Yes, WPF is going their own way.

 

They redefined how PropertyChanged (INotifyPropertyChanged) is handled, and they redefined how bindable collections are handled.

 

I think you can argue that the WPF definitions are superior, and you can wish that WinForms had done them this way too. But that’s rather pointless. WPF is learning from the things WinForms did right and wrong, and so we’re seeing progress.

 

But the interim is painful, because anyone with a business object layer (not just CSLA) is left trying to deal with the old and new requirements at the same time.

 

Rocky

 

From: rsbaker0 [mailto:cslanet@lhotka.net]
Sent: Wednesday, January 21, 2009 9:32 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Feature input request: WPF collections

 

Interesting, because BindingList<T> is in the System.ComponentModel namespace, not the System.Windows.Forms namespace.

Does this mean that WPF is basically going it's own way as far as the previous support in .NET for building components? It looks to me like System.ComponentModel at least makes an attempt to be "WinForms agnostic", but I haven't looked at it closely enough to state this with certainty.



ajj3085 replied on Wednesday, January 21, 2009

Indeed..

To make matters worse for me, I'll likely have to heavily integrate Wpf into my existing WinForms application.

I'd love to move to Wpf.. but I have other things more important to the business to handle.

rfcdejong replied on Wednesday, January 21, 2009

Maybe nice to have a poll about this? Does the CSLA forum support polls? :)

Anyway, we are building on WPF and we'll run into this binding problem as well sooner or later. I though the IBindinglist would work perfectly in WPF.

Option 1 (won't be that double work same as option 2?) or else Option 3

PS: xaml doesn't fully support generics yet, but thats offtopic ;) I was just frustrated today about that, did spend 8 hours on trying to get generics working in our xaml base class.

RockfordLhotka replied on Wednesday, January 21, 2009

>Maybe nice to have a poll about this?
>Does the CSLA forum support polls? :)

Yes, it does support polls, and I've used them from time to time. I need a
better sense of what options I'm willing to consider before asking which of
those people prefer.

Rocky

RockfordLhotka replied on Wednesday, January 21, 2009

> To make matters worse for me, I'll likely have to heavily

> integrate Wpf into my existing WinForms application.

Which is a driving reason for me starting this thread, in the hopes that there’s some solution that supports WinForms, WPF and a combination.

 

I don’t want to give up on the idea of CSLA objects supporting all existing UI technologies. That’s been a core principle of the framework all these years.

 

I suspect the answer is reworking the collection model so the underlying collection (BLB) is more separate from the UI view requirements. Whether it directly imbeds WinForms or WFP (or neither) support, it starts to appear that at least one of the UI technologies will need to use some separate view construct.

 

Rocky

 

Jack replied on Wednesday, January 21, 2009

Maybe an app.config value can somehow determine the default view construct which makes it easier for a legacy application owner to choose which has the less impact?

 

From: Rockford Lhotka [mailto:cslanet@lhotka.net]
Sent: January-21-09 12:13 PM
To: jaddington@alexandergracie.com
Subject: RE: [CSLA .NET] RE: RE: Feature input request: WPF collections

 

> To make matters worse for me, I'll likely have to heavily

> integrate Wpf into my existing WinForms application.

Which is a driving reason for me starting this thread, in the hopes that there’s some solution that supports WinForms, WPF and a combination.

 

I don’t want to give up on the idea of CSLA objects supporting all existing UI technologies. That’s been a core principle of the framework all these years.

 

I suspect the answer is reworking the collection model so the underlying collection (BLB) is more separate from the UI view requirements. Whether it directly imbeds WinForms or WFP (or neither) support, it starts to appear that at least one of the UI technologies will need to use some separate view construct.

 

Rocky

 



tmg4340 replied on Wednesday, January 21, 2009

RockfordLhotka:

I suspect the answer is reworking the collection model so the underlying collection (BLB) is more separate from the UI view requirements. Whether it directly imbeds WinForms or WFP (or neither) support, it starts to appear that at least one of the UI technologies will need to use some separate view construct.

A "BindingSource" for CSLA objects?  That's another idea.  BLB is implemented as a generic collection, and then you create WinForms and WPF wrappers that implement the UI plumbing.  I still say they should be in separate assemblies, but that may be the best way to make it work.

- Scott

ajj3085 replied on Wednesday, January 21, 2009

Isn't the grid still in CTP?  Is there any chance that this functionality will be added before release?  I know on the codeplex discussion others have been asking for it.

Also, I found this blog.  Maybe this helps in some way? 

Finally.. is the problem just the automatic sorting?  Does everything else work?  If it's just sorting, I think I've seen that doing myGrid.DataSource  = from myBoList select items; will enable sorting.  And, if it is just sorting, dumping an entire UI technology (even if it is legacy.. but even at my company we still have 16-bit applications that we're just starting to get rid of) just so automatic sorting works seems pretty extreme.

RockfordLhotka replied on Wednesday, January 21, 2009

> Finally.. is the problem just the automatic sorting?

 

At the moment, to my knowledge, this is the only issue. My primary concerns are twofold – this could be the tip of the iceberg (more issues will arise); and I really don’t want CSLA to be a second-class citizen in what will be the mainstream technology for the next many years.

 

Again, I want to reinforce that I’m just putting out all the options. I’m not giving a lot of thought to dropping WinForms support, as I agree with the ongoing value of WinForms. But it would be dishonest to leave that option off the list.

 

I’m really hoping for some other solution to present itself. That ExtendedCollectionViewSource idea is interesting, and maybe could be adapted into CSLA in some manner. It still requires some non-standard XAML binding though.

 

I’d almost rather do the reverse – make BLB become an ObservableCollection<T>, and implement an IBindingList wrapper for WinForms support. That’d be a breaking change, as it would impact existing code – but I’d rather have the “ugly” code support legacy, and the nice code support the future.

 

Rocky

Jack replied on Wednesday, January 21, 2009

Rocky,

I would agree with your last statement - make BLB an ObservableCollection and leave the legacy with a wrapper.  While it is painful for existing legacy apps to move forward, most legacy apps don't likely need to have the latest and greatest CSLA version in place.

I don't have anything technically to add other than likely a best scenario for having a wrapper implemented is in such a way that the worst case is doing a find/replace on the BusinessBaseList<T> across the app to solve most of the implementation issues.  Then there are compiler errors so anything not picked up /w a find/replace can be found.

If I told any of my clients I was going to upgrade the application framework that touched every object in the application they would have huge concerns and likely the testing effort to appease them outweighs the need to use some new feature that a big upgrade to the framework may provide.

Of course I'm now biased as I have no legacy CSLA apps :-).  But if the tradeoff for building future apps is that there are less workarounds and hoops in the framework then that is one less issue on the learning curve for a new technology.

Just my two cents

Jack

Jack replied on Wednesday, January 21, 2009

After reading the prior post – about suggestion #2 and maintaining two streams…  Isn’t that essentially going to happen with a wrapper anyways?

 

Any breaking logic that you add to the WPFxxx objects needs to be translated into the wrapper no?

 

While dramatically simplifing - would you not have BusinessBaseList<T> then become Wrapper (WpfBusinessBaseList<T>) and all the base objects simply migrate to wpfBaseClasses?

 

Or can you split the CSLA library into different pieces such that CSLA.WinForms.BusinessBase<T> = Wrapper(CSLA.Core.BusinessBase<T>) and CSLA.WPF.BusinessBase<T> = CSLA.Core.BusinessBase<T>?  I don’t know if you can do something at the config level where you can have CSLA.Core be the default and you reference CSLA.WinForms if and only if you aren’t doing WPF/Silverlight etc.

 

Then hopefully all you are maintaining is the Core Library and 1 or more wrapper libraries as you obsolete technologies?

 

Jack

 

 

From: Jack [mailto:cslanet@lhotka.net]
Sent: Wednesday, January 21, 2009 7:54 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] RE: Feature input request: WPF collections

 

Rocky,

I would agree with your last statement - make BLB an ObservableCollection and leave the legacy with a wrapper.  While it is painful for existing legacy apps to move forward, most legacy apps don't likely need to have the latest and greatest CSLA version in place.

I don't have anything technically to add other than likely a best scenario for having a wrapper implemented is in such a way that the worst case is doing a find/replace on the BusinessBaseList<T> across the app to solve most of the implementation issues.  Then there are compiler errors so anything not picked up /w a find/replace can be found.

If I told any of my clients I was going to upgrade the application framework that touched every object in the application they would have huge concerns and likely the testing effort to appease them outweighs the need to use some new feature that a big upgrade to the framework may provide.

Of course I'm now biased as I have no legacy CSLA apps :-).  But if the tradeoff for building future apps is that there are less workarounds and hoops in the framework then that is one less issue on the learning curve for a new technology.

Just my two cents

Jack


RockfordLhotka replied on Wednesday, January 21, 2009

Not entirely.

 

What I don’t want to do is maintain BLB twice. If you look at BLB, it is quite large, and quite complex.

 

One of the reasons SortedBindingList, FilteredBindingList and LinqBindingList exist is to pull out some of the complexity by separating concerns where possible. But some concerns are harder to separate – specifically the data binding interface implementations.

 

The problem, ultimately, is that WinForms and WPF data binding are designed with the assumption that the data collection will implement certain interfaces. While they may partially support lesser collections, they only _really_ work with collections that implement the right interfaces.

 

That forces the collection to assume a certain level of complexity, because these interfaces aren’t always trivial. Even if they _look_ trivial, they often have idiosyncrasies of implementation that make them complex. So favoring composition is a good ideal – but it is challenging when the collection itself must implement the interfaces, and must raise the events.

 

Now we’re faced with a case where WinForms and WPF want different interfaces, and a given collection can’t implement both, because two of the interfaces directly conflict. Implement both and you get a non-functional result.

 

One solution is to move these interfaces up, out of the collection itself, and into wrappers. On one level this seems elegant, and offers better separation of concerns.

 

But to the UI developer, you just complicated their life, because now they must remember to insert this wrapper between the UI and the collection, or they don’t get the desired result. Often this means they are blocked from using RAD features of VS, or at least they must go in manually after the RAD feature and tweak the result.

 

Maybe that’s the price we pay, but it is a little sad imo, because I _like_ using RAD features and being productive…

 

Rocky

 

From: Jack Addington [mailto:cslanet@lhotka.net]
Sent: Wednesday, January 21, 2009 9:17 AM
To: rocky@lhotka.net
Subject: RE: [CSLA .NET] RE: Feature input request: WPF collections

 

After reading the prior post – about suggestion #2 and maintaining two streams…  Isn’t that essentially going to happen with a wrapper anyways?

 

Any breaking logic that you add to the WPFxxx objects needs to be translated into the wrapper no?

 

While dramatically simplifing - would you not have BusinessBaseList<T> then become Wrapper (WpfBusinessBaseList<T>) and all the base objects simply migrate to wpfBaseClasses?

 

Or can you split the CSLA library into different pieces such that CSLA.WinForms.BusinessBase<T> = Wrapper(CSLA.Core.BusinessBase<T>) and CSLA.WPF.BusinessBase<T> = CSLA.Core.BusinessBase<T>?  I don’t know if you can do something at the config level where you can have CSLA.Core be the default and you reference CSLA.WinForms if and only if you aren’t doing WPF/Silverlight etc.

 

Then hopefully all you are maintaining is the Core Library and 1 or more wrapper libraries as you obsolete technologies?

 

Jack

TAC replied on Wednesday, January 21, 2009

RockfordLhotka:

Now we’re faced with a case where WinForms and WPF want different interfaces, and a given collection can’t implement both, because two of the interfaces directly conflict. Implement both and you get a non-functional result.


Just out of curiosity what are the interfaces?
For WinForms it's IBindingList,
Is the WPF ones INotifyCollectionChanged and INotifyPropertyChanged?

Just quickly looking at them I can't see why a class can't implement both. Or is it a case of you can but binding gets confused? If it is that isn't that really a microsoft bug? Shouldn't their WPF binding only use IBindingList if the new interfaces don't exist?
So the ideal solution would be for Microsoft to fix this up? Of course this is also the option which we have the least control over.

TAC replied on Wednesday, January 21, 2009

Just found where you talk about it in Expert C# 2008 Business Object (page 52 if anyone is interested) and from how you describe the problem couldn't you solve it with a flag? Collections would implement IBindingList and INotifyCollectionChanged and you could then have a property...
public bool RaisesIBindingListEvents { get; set; }
then for all the IBindingList stuff would start with
if (!RaisesIBindingListEvents)
    return;

This seems like the best solution to me.

---
Chris.

RockfordLhotka replied on Wednesday, January 21, 2009

The problem is that WPF data binding notices that the collection implements IBindingList and treats it differently.

 

There’s no way, at runtime, to decide what interfaces a type does or doesn’t implement – that’s a compile-time choice…

 

Rocky

 

 

From: TAC [mailto:cslanet@lhotka.net]
Sent: Wednesday, January 21, 2009 8:52 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: RE: Feature input request: WPF collections

 

Just found where you talk about it in Expert C# 2008 Business Object (page 52 if anyone is interested) and from how you describe the problem couldn't you solve it with a flag? Collections would implement IBindingList and INotifyCollectionChanged and you could then have a property...
public bool RaisesIBindingListEvents { get; set; }
then for all the IBindingList stuff would start with
if (!RaisesIBindingListEvents)
    return;

This seems like the best solution to me.

---
Chris.


Justin replied on Thursday, January 22, 2009

My vote would be choose the "best" (probably wpf) implementation currently and make the other one a wrapper.

My second choice would make a base implementation and have both winforms and wpf be wrappers.

I take issue with MS on this as they should have worked out data binding properly in .Net 1.0 so it is not a moving target. Data binding should also not be a UI concern, it should be baked into the base runtime for all objects.

Take a look at key-value observing in the Apple/Cocoa/obj-c world and how you don't have to manually call any kind of NotifyChanged("PropertyName") in your setters as the runtime can detect and raise changed events on any object property. Built on top of that they give you undo/redo nearly for free with NSUndoManager. This has been done for years over there.

MS should really build in some sort of property event system in reflection, so say a PropertyInfo object just has BeforeChange/AfterChange events, but I digress hopefully they will at least just stick with the WPF model for a while.

Look here as a side note if you are interested in Apples approach: http://dotnetaddict.dotnetdevelopersjournal.com/cocoa_wpf_bindings.htm

dctc42 replied on Friday, January 23, 2009

That's a shame. Improving on IBindinlList with INotifyCollectionChanged/INotifyPropertyChanged is fine but if MS is still supporting IBindingList you would think that binding logic would first look for INotifyCollectionChanged/INotifyPropertyChanged  and then fallback on IBindingList. This "feels" like an implementation  mistake.

Anyway,  IBindingList has methods called AddNew, EndNew, CancelNew. I don't see what repleces these in ObservableCollection<T>. Isn't this a loss of capability?

Currently, overriding OnAddingNew lets me call the right factory method when adding items to BLB through a grid or other UI binding mechanism.

If there is no real funtionality loss my vote is for moving to natively support Wpf binding mechanisms and, if practival, adding a wrapper that supports IBindingList.

IMO, Csla can't choose legacy support (sorry for using the L word guys) over staying current.

ajj3085 replied on Friday, January 23, 2009

Well, ideally the Wpf grid from MS would be fixed to honor IBindingList OR Observable collection, but not both.  Is there any chance to of getting this done?  Maybe Rocky has a favor he can call in from someone inside MS.  Smile [:)]

RockfordLhotka replied on Friday, January 23, 2009

Yeah, that’d be nice :)

 

The problem now, of course, is that they’re working on the third (fourth?) release of WPF and have backward compat issues and so forth. So a fundamental change in how they treat IBindingList objects is probably not real likely.

 

The reasoning, btw, behind what they do, is that IBindingList itself supports sorting – if the collection implementing the interface supports it anyway. BindingList<T> doesn’t sort, which is really too bad. But they apparently didn’t feel they should create a sorted view over a collection that could support sorting itself, because that could result in some very unexpected results.

 

On the other hand, in my experiments, binding WPF to a SortedBindingList doesn’t result in sorts working. And that’s surprising, since it was my understanding that they delegated the sorting to the IBindingList implementation. Certainly they throw an exception if the IBindingList.SupportsSorting returns false, so you would expect they’d call IBindingList.ApplySort() if it returned true…

 

Really the whole thing seems very strange and poorly thought out to me.

 

Rocky

 

From: ajj3085 [mailto:cslanet@lhotka.net]
Sent: Friday, January 23, 2009 1:09 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: RE: RE: Feature input request: WPF collections

 

Well, ideally the Wpf grid from MS would be fixed to honor IBindingList OR Observable collection, but not both.  Is there any chance to of getting this done?  Maybe Rocky has a favor he can call in from someone inside MS.  Image removed by sender. Smile <img src=">


FatPigeon replied on Saturday, January 24, 2009

I have a use case that I spent some time trying to implement last summer that I think has a bearing on this discussion.

It is basically the RootChildGrandchildWinFormTest where each row in a grid is bound to a root business object. Other controls on the form are bound to other details of the business object profile. These other controls could include additional grids bound to child lists.  The ERLB uses the IEditableObject.EndEdit to trigger the save method of each parent business object. 

The main problem I could not solve was that the WinForms DataGridView fires EndEdit whenever a grid row is departed, even if the user has only left the row to move to a child control bound to the same business object. At this stage the user may not have finished editing the business object and there is no reason to assume that business object is valid, so saving it at this stage does not make sense. I only want the ‘save’ to be triggered if the user moves to another row in the root grid.

This is a very different style of user interface to the Project Tracker example so it may be that CSLA is not intended to support this type of use case, but if it is, then the following may be relevant.

I have wondered whether EndEdit should be used to trigger save. The documentation for IEditableObject says that the interface ‘Provides functionality to commit or rollback changes to an object that is used as a data source’. Here it must be intended that the term ‘data source’ refers to the business object and not the persisted data store. An example of this is the implementation of the interface in the dotnet dataset class. The developer is free to leave persistence of the dataset until after allowing the user to make several edits. There is nothing to force persistence on every call to EndEdit.

I have briefly looked at the WPF grid. It appears that the EndEdit may be even more problematic in that it is triggered even when the user toggles to another application and not even left the grid row at all – but this may just be the CTP version. However, it appears that there may be an alternative for triggering persistence. The WPF data grid has a ‘CurrentChanging’ event. It seems this is only triggered when the user tries to change the current row in the data grid – and it can be cancelled. It occurs to me that this would be a good place to test for business object validity, canceling the event if invalid and saving if valid.

If the above makes sense then I would propose that option 2 is chosen. I suggest the WinForms classes are left to support the WinForms interface while a new set of WPF classes are developed that support the WPF interface including the above scenario.

I do not think that this would involve twice the effort. Having one complex set of classes can sometimes be more time consuming (and less fruitful) than two simple sets.

Regards,

Patrick

ajj3085 replied on Sunday, January 25, 2009

RockfordLhotka:
The problem now, of course, is that they’re working on the third (fourth?) release of WPF and have backward compat issues and so forth. So a fundamental change in how they treat IBindingList objects is probably not real likely.


I'm confused; MS has released prior versions of the DataGrid for Wpf?  I thought they were only now about to do so, and that it was in CTP.  I think they've broken things between CTP versions previously?

RockfordLhotka replied on Monday, January 26, 2009

The support for IBindingList pre-dates the grid. Most people are just seeing the results of the choice now that there is a grid.

 

You can use the same binding/sorting techniques that the grid uses when binding to a ListBox or other list control. And you’ll get the same results (or lack thereof) because the underlying plumbing is the same.

 

Rocky

 

 

From: ajj3085 [mailto:cslanet@lhotka.net]
Sent: Sunday, January 25, 2009 12:06 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: RE: RE: RE: Feature input request: WPF collections

 

Image removed by sender.RockfordLhotka:

The problem now, of course, is that they’re working on the third (fourth?) release of WPF and have backward compat issues and so forth. So a fundamental change in how they treat IBindingList objects is probably not real likely.



I'm confused; MS has released prior versions of the DataGrid for Wpf?  I thought they were only now about to do so, and that it was in CTP.  I think they've broken things between CTP versions previously?


TAC replied on Thursday, January 29, 2009

Is this the same issue?
https://connect.microsoft.com/feedback/ViewFeedback.aspx?SiteID=212&FeedbackID=344858&wa=wsignin1.0
Because Microsoft says it's been Fixed, they don't say what version it was fixed in, but you'd think the VS2010 CTP would definitely have the fix.

RockfordLhotka replied on Thursday, January 29, 2009

Maybe it is fixed. I ran into it early on – before WPF was released – and never looked back.

 

It would sure be nice if BLB can just implement INotifyCollectionChanged and magically get all the good stuff. But I very much doubt it is that easy. I suspect ObservableCollection<T> is just a much more robust collection type than BindingList<T> - at least in terms of sorting.

 

I shudder to think about manually implementing IBindingList again (so BLB could inherit from ObservableCollection). I had to implement IBindingList in CSLA 1.x, and it was a PITA – I threw myself a little party when .NET 2.0 included BindingList<T>. But that might be the answer, and it would be worth it if there really is a solid answer.

 

Rocky

ajj3085 replied on Friday, January 30, 2009

RockfordLhotka:
It would sure be nice if BLB can just implement INotifyCollectionChanged and magically get all the good stuff. But I very much doubt it is that easy. I suspect ObservableCollection<T> is just a much more robust collection type than BindingList<T> - at least in terms of sorting.


Hmm... maybe someone here that has run into the issue of sorting could implement INotifiyCollectionChanged in their custom BLB subclass, and let us know if it works correctly or not?  Anyone?

jgdove replied on Friday, February 06, 2009

I've been having the sorting problem with the new DataGrid, and was able to get it working using the ExtendedCollectionViewSource posted here:

http://www.wpfmentor.com/2008/12/how-to-sort-bindinglist-using.html

There's a similar post that I haven't played around with, but seems more in depth (modifies the collection to raise the same notifications that ObservableCollection raises):

http://www.wpfmentor.com/2008/12/observable-collections-independent-of.html

Maybe they'll help.

CrispinH replied on Thursday, March 26, 2009

I've been using CSLA since the early days when it was written in classic VB and have always treated it as as ideas factory - a framework upon which I should build to suit my own purposes - rather that a commercial product which requires product support from the seller - or in this case Rocky.  I therefore favour CSLA moving into WPF and leaving WinForms behind.

Obviously I had a disruptive change moving from the Classic VB to VB.NET versions of CSLA and  I expect that this won't be the last time a disruptive change will occur.  To deal with this my strategy moved from having a single version of CSLA to a version of CSLA for each client based upon a master copy.  If I make a change to one version of CSLA that I think might be beneficial to another, I then use a tool like Beyond Compare to show the differences between versions at source code level.  However in practice, I find that once project is stable, there is little requirement to make changes (if it ain't broke, don't fix it) so only the master copy gets updated.

So what to do with the legacy WinForms versions of CSLA?  In the same way that the VB version of CLSA is now supported by the CSLA community work, the WinForms versions of CSLA could also be supported by 'the community'.

Crispin

Kevin Fairclough replied on Tuesday, April 28, 2009

Hi,

What is the situation with this problem?  Does CSLA (latest) fully support WPF data grids?
Looking @ Issue Tracking, what does red/green flag mean?

Regards
Kevin

RockfordLhotka replied on Tuesday, April 28, 2009

I don’t use the red/green flag column, and don’t really know its intent.

 

CSLA collections are IBindingList at this point, and you will need to use one of the known techniques (from google) to wrap an IBindingList with an ObservableCollection at this time.

 

The “fix” to make CSLA collections support WPF will be a breaking change, and I’ll probably do it in CSLA .NET 4.0. As you can tell, there’s a lot of concern about any solution I might use, so ultimately I’m going to break some/all users thanks to WPF being so incompatible with the rest of .NET.

 

I guess what I’m saying, is you will know when it “fully supports” WPF data grids, because there’ll be a lot of noise associated with this change, and it won’t sneak in through a point release :)

 

Rocky

 

 

From: Kevin Fairclough [mailto:cslanet@lhotka.net]
Sent: Tuesday, April 28, 2009 10:55 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Feature input request: WPF collections

 

Hi,

What is the situation with this problem?  Does CSLA (latest) fully support WPF data grids?
Looking @ Issue Tracking, what does red/green flag mean?

Regards
Kevin


rfcdejong replied on Monday, July 20, 2009

Crap.. we ran into this :)

I vote for dumping Windows in CSLA 4.0 (or add those directives)

If the business objects would had been of ObservableCollection then IsSyncronisedWithCurrentItem and stuff with ICollectionView.GetDefaultView() would just work nice i suppose. We have a problem because we databind the csla objects directly and not wrap them in a ViewModel.

I find this a high priority since alot of WPF databind power goes down the drain now.

RockfordLhotka replied on Monday, July 20, 2009

As I understand it, there are changes coming in WPF 4.0 data binding that make it more important to switch to ObservableCollection.

 

So I do think what I’ll end up doing for CSLA .NET 4.0 is providing primary support for WPF, and secondary support for Windows Forms. Kind of the reverse of what I’m doing now, where I try to make sure things work ideally in Windows Forms and function in WPF.

 

That’s not a final decision, and I’ll know more once I really dig deep into the issues later this year, but I anticipate this to be the case.

 

The hard part is that it could make upgrading from 3.7 to 4.0 challenging for Windows Forms users. But the good part is that it will keep CSLA .NET relevant as people move to WPF – which I suspect will happen faster once Visual Studio 2010 comes out with decent designer support.

 

Rocky

 

MadGerbil replied on Tuesday, July 21, 2009

I like the solution of primarily supporting WPF - right out of the box - with support for WinForms being secondary and requiring configuration.

Although the move to WPF is painful the little bit of study I've done in it convinces me it is the right choice. The technology brings way too much to the table to ignore.

My next application will be WPF and I'd like to use CSLA 4.0. When is that due out? Early next week?

rfcdejong replied on Tuesday, July 21, 2009

Early next week... that would be great lol

I did read alot about differences between ObservableCollection and BindingList, people say that they like BindingList more since it has PropertyChanged etc. But for WPF the ObservableCollection is more powerfull as it supports functionality for ICollectionView and the collection notificates every change within it's collection unlike the bindinglist. The BindingList is a strange object containing so many differend operations in one.. having an generic List as well, the ObservableCollection doesn't. So i wonder how Rockford is going to impliment it. Also implimenting INotifyPropertyChanged etc.

shawndewet replied on Tuesday, April 28, 2009

   I fully agree with Crispin.  Keep moving forward!

RockfordLhotka replied on Wednesday, January 21, 2009

Yes, you can implement IBindingList and INotifyCollectionChanged. And Windows Forms will work fine, because it ignores INCC. But WPF will have no end of trouble because it honors both (more or less).

 

I know this, because one alpha version of CSLA 3.5 did implement both, and it was bad.

 

Rocky

ajj3085 replied on Wednesday, January 21, 2009

Jack:
I would agree with your last statement - make BLB an ObservableCollection and leave the legacy with a wrapper.  While it is painful for existing legacy apps to move forward, most legacy apps don't likely need to have the latest and greatest CSLA version in place.


I really disagree with this statement.  I have a WinForms app; only two years old, and I had started on 2.0 Csla and have been keeping up with it since.  The reason is that each version of Csla has offered substantial improvements over previous version; per type rules saved memory and improved performance, the 3.5 changes are allowing me to reduce the amount of code I have to write (and decrease the bugs because I forgot or didn't implement the eliminated code corretly).  My UI is WinForms, but the application on a whole is hardly legacy.  It's still evolving.

While I can sneak in Csla updates (and thus simpify code) because I have unit tests, I can't as easily move to a new UI technology.  Testing the UI is still largely a manual task.

Jack replied on Wednesday, January 21, 2009

I suppose it was quite broad based but everyone has a different opinion of what constitutes legacy :-) – but the more mature CSLA becomes the less revolutionary the changes to older technology becomes until they become evolutionary.  Were not many of the improvements in 3.5 driven from the need to work in Silverlight? 

 

Nonetheless each app speaks for itself so one cannot generalize perhaps as much as I did.

 

 

From: ajj3085 [mailto:cslanet@lhotka.net]
Sent: January-21-09 10:58 AM
To: jaddington@alexandergracie.com
Subject: Re: [CSLA .NET] RE: Feature input request: WPF collections

 

Jack:

I would agree with your last statement - make BLB an ObservableCollection and leave the legacy with a wrapper.  While it is painful for existing legacy apps to move forward, most legacy apps don't likely need to have the latest and greatest CSLA version in place.



I really disagree with this statement.  I have a WinForms app; only two years old, and I had started on 2.0 Csla and have been keeping up with it since.  The reason is that each version of Csla has offered substantial improvements over previous version; per type rules saved memory and improved performance, the 3.5 changes are allowing me to reduce the amount of code I have to write (and decrease the bugs because I forgot or didn't implement the eliminated code corretly).  My UI is WinForms, but the application on a whole is hardly legacy.  It's still evolving.

While I can sneak in Csla updates (and thus simpify code) because I have unit tests, I can't as easily move to a new UI technology.  Testing the UI is still largely a manual task.


HappyJack replied on Wednesday, January 21, 2009

Rocky,

If the problem is just with the datagrid in WPF, what about deriving a new datagrid and try to fix the grid problems with IBindingList.  I have not looked at the WPF datagrid at all so I'm not sure if it is possible.  Another idea would be to create a new helper collection that can wrap a CSLA bindingList collection and pass the updates back and forth, kind of like the filteredlist.  

 

tmg4340 replied on Wednesday, January 21, 2009

I'll start by saying I have no experience with Silverlight, and thus have spent no time looking over the Silverlight support built into CSLA.  However, I have read enough of what's going on that I feel qualified to step blindly into this discussion.  Smile [:)]

It seems to me that you've already gone down the path of both #1 and #2.  Option #1 was covered when you added compiler directives in CSLA 3.0 to handle .NET 2.0 and .NET 3.0 support.  Option #2 was covered (albeit in a slightly different way) when you added Silverlight support.  I have never been a huge fan of compiler directives, though I readily admit they have some real use.  And while adding Silverlight support didn't require a copy of existing objects, it did require a fair amount of adjunct objects be created.

While I know what it does to you, I'm wondering if #2 isn't the best option.  You could separate the WPF and WinForms support into separate assemblies, thus allowing developers to reference the piece they need.  And, as you've noted, the sorting support may be just the first change to contend with.  How much more complicated does your compiler-directive code get as WPF and WinForms diverge even more?  Sure, 80-90% of the code will be the same - and to be blunt, it sucks to have to have it twice.  But in the world of isolating the stuff that changes...

Again, I know what that does to you - beyond the maintenance work you already alluded to - but it's "The Microsoft Way".  Whether that's a good enough reason for you to make your life even harder... well, that I can't help you with.  Smile [:)]  And while I admit that the fact that I don't have to do the work is something of a contributing factor, I'd probably make this choice even if I were.

HTH

- Scott

maxal replied on Sunday, January 25, 2009

Rocky,

I understand you desire to make WPF support to be native for your objects and totally agree. And since I was one of the people struggling witn sorting in WPF DataGrid, I would like to thank you for giving this problem such high priority and discussing it.

However, here is the scenario I can easily imagine in our company. In fact, I see it coming. We have WinForms application, that nobody wants to rewrite at the moment, but we want to develop some new tools with WPF. We would want them to be installed together, and use same CSLA objects codebase. Neither of suggested approaches handles this problem, as I can see.

People were talking about wrappers, and that's may be really the solution. Wherever we use lists in WinForms applications, we use BindingSource component. Will it be possible to just create something like CslaBindingSource that would link to these new WPF friendly lists, and take over all  troubles? It may not help us at the moment, but for others, who would start with WinForms application and put CslaBindingSource from the beginning (and the would have to do it), later they could transition to WPF smoothly.

RedShiftZ replied on Monday, July 20, 2009

Leaving Winforms is not really an option for us. We just started developing a new suite of winforms applications using CSLA. We choose CSLA 3.5 for its winforms support and its portable objects.

If CSLA were to leave winforms behind, you would be leaving us behind. We are just not interested in WPF right now or for the foreseeable future.

 I would vote for the separate assemblies idea as I prefer to just compile and use only what I need.

That is my view on the matter.

Thanks,

Jeff

Copyright (c) Marimer LLC