I have seen how these properties do not raise the PropertyChanged event so you cannot bind to these properties. I am curious if other people have sought to bind to these in order to add functionality to Windows Forms for instance if the object goes from IsNew = true to false then enable other parts of the form which allow child features...
Also there are no specific events raised for these properties. I think it would be useful to add events specific to these properties and also pass the old and new value if it is not simply a boolean, rather say an enum...
Thanks
Hi,
We plan to add events to these properties for CSLA 4.5 (and at the same time terminate support for Windows Forms).
Windows DataBinding is not suitable for having events on the "status" properties due to how OnPropertyChanged is handled in the UI (ie: all properties but the one that has changed is reread per OnPropertyChanged). Imagine the impact with 5-6 status properties and reread of all properties (including child properties with nested BindingSources) x times per time a <bo> property has changed.
We rather recommend to use ReadWriteAuthorization or create your own components or implement this in BindingSource.CurrentItemChanged for Windows Forms development.
For Xaml (WPF/SL) we recommend to use the Csla.Xaml.ViewModel as baseclass for viewmodels that exposes status properties with events for databinding.
We plan to add events to these properties for CSLA 4.5 (and at the same time terminate support for Windows Forms).
"Terminate" is such a strong word :)
I think what will happen is that we'll still support WinForms, but it might be less optimal for data binding, because we'll be raising property changed events as necessary for WPF/WinRT.
So WinForms will still work, but forms with hundreds of data bound controls may perform less well.
Dear JonnyBee,
I understand you desire to support newer UIs, and I'm see Rocky clarified your comment, as his positions as I understand it, is currently that while no enhancements will be forthcoming for WinForms, backwards compatibility will be maintained for the time being (or while such is possible).
So, I encourage you think a little more about your position and see if there isn't a creative way to not impacting perfomance for WinForm which, I believe a lot of Line of Business Developers (LOBDs) out there are still actively using, and will probably keep doing so until Windows 9, when it is obvious what Microsoft's best position is for a future UI. I accept WPF and Silverlight have wonderful new 'pretty' features (haven't looked at WinRT) and may make WinForms look dated, but they really don't offer anything that's a real need for LOBD's who operate to tight schedules, which typically doesn't permit learning a new more difficult to use UI just to make things pretty.
Maybe you could add a switch that allows those extra events to be turned off for the rest of us still working with WinForms.
I won't be moving my 500+ WinForms CSLA application to another UI until its obvious which Microsoft one is going to be the lead candidate for the next few years. I didn't jump to WPF and Silverlight partially because of their learning curve and lack of compelling must have features, but more because I did not see Microsoft adopt those UIs for their mainstream applications. I'm now waiting to see when they are willing to start adopting one of their own new UIs for their business applications going forward. That's when I feel I will need to make the move to a new UI.
Thanks for listening, and let me conclude by saying I love CSLA.
Des Nolan
It might be the case that Windows Forms apps will need to stick with CSLA 4.3 to remain optimal. Time will tell - we're not yet actively working on 4.5, so it is premature to say what will happen exactly.
I fully appreciate that people will continue to run WinForms apps on Windows 8, and maybe even Windows 9. Fortunately Microsoft isn't doing much (if anything) to WinForms beyond keeping it running. I'm already pretty confident that CSLA 4.3 will work on Win8 on the Desktop side - where WinForms lives.
Whether we can continue to support increasingly disparate platforms (WinForms vs WinRT/Metro) in a single code base is debatable. Eventually we'll hit a show stopping issue. The collection differences between WinForms and WPF are a near-show stopper, and the solution isn't ideal. I'm sure that sort of thing will only get worse - and at some point I'll decide it is too painful to make sense to support both.
At that point, WinForms will be pinned to some version of CSLA, and subsequent versions won't support WinForms.
It is hard to see an alternative, when WinForms is unchanging and the rest of the dev platform is evolving. Frankly I'm a little surprised that we've been able to accomodate the delta as well as we have given 6+ years of this platform deviation.
Copyright (c) Marimer LLC