Could someone provide me a roadmap for embarking on adding INotifyPropertyChanging support to my Entity classes? Or perhaps this is already available somewhere?

I think that is not built-in. You can use INotifyPropertyChanged, is that enough for you? What are you trying to achieve?

I'm going to use Continuous Linq (clinq.codeplex.com) across multiple sub-collections of my data, and if the entity implements INotifyPropertyChanging, it can save a lot of effort and memory watching the entities.

Thanks

There is nothing to stop you adding any code you want to the generated entities. It can be added to user code regions, in partial classes, or you can modify the templates to generate it for you. Not anyone has tried clinq yet though, let us know how you get on.

Matt

Implementing a new interface probably would require a bit lower level change wouldn't it? Definitely not a user code region thing. Can you point a LLBLGenewbie in the right direction?

Yep, good point. This means that you have 2 options - either to modify the templates, or to create your own entites that inherit from the generated code and also implement the required interface.

I have to say though, that both of the approaches are fairly advanced. If you are an LLBLGen newbie then perhaps you should spend some time getting more familiar with the basics first

LLBLGen newb != developer newb. I'll muddle through the Template Studio, I guess.

Perhaps you would consider Obtics instead. Not sure why you need INotifyPropertyChanging.

Jeremiah & I have a screencast demonstrating LLBLGenPro with Obtics. Please see here:

http://www.GeniusCode.net

Hope this helps!

Ryan

At the moment, I'm using CLINQ for it's support for SelectMany

class Sample
{
   public ObservableCollection<MeasurementEntity> Measurements;
}

class Group
{
   public ObservableCollection<Sample> Samples;
}

//AllMeasurements presents itself as a single collection of all Measurements in all samples
ReadOnlyContinuousCollection<MeasurementEntity> AllMeasurements = TheGroup.Samples.SelectMany(sample => sample.Measurements);

CLINQ doesn't require INotifyPropertyChanging, but its presence provides it the ability to work more efficiently.

Now that I dig into the LLBL code a bit more, it seems EntityBase2 is the proper place to add support. And as I dig further, I see all the places OnPropertyChanged is called and cringe.

I've invested enough time in this exploration for now. I think if I were to hack it in later, I'd do something with a validator that always returns true and triggers the PropertyChanging method. Is there an official feature request channel to go through?

As an aside: one thing I noticed in my poking around was

        protected virtual void FlagAllFieldsAsChanged()
        {
            foreach( IEntityField2 field in _fields )
            {
                OnPropertyChanged( field.Name );
            }
        }

I don't know if there are other reasons for this impl, but PropertyChanged(this, null); is intended to serve the purpose of notifying that all properties for the object have changed.

tmatelich wrote:

Now that I dig into the LLBL code a bit more, it seems EntityBase2 is the proper place to add support. And as I dig further, I see all the places OnPropertyChanged is called and cringe.

Sound nice. You also could look into CommonEntityBase. That depends on what are you trying to do and where you want to rise the event.

tmatelich wrote:

Is there an official feature request channel to go through?

Yes, you can post feature request in the "Feature request" forum (http://llblgen.com/tinyforum/Threads.aspx?ForumID=35)

tmatelich wrote:

As an aside: one thing I noticed in my poking around was

        protected virtual void FlagAllFieldsAsChanged()
        {
            foreach( IEntityField2 field in _fields )
            {
                OnPropertyChanged( field.Name );
            }
        }

I don't know if there are other reasons for this impl, but PropertyChanged(this, null); is intended to serve the purpose of notifying that all properties for the object have changed.

That method is intended to signal to bound controls that all fields have been changed.

tmatelich wrote:

As an aside: one thing I noticed in my poking around was

        protected virtual void FlagAllFieldsAsChanged()
        {
            foreach( IEntityField2 field in _fields )
            {
                OnPropertyChanged( field.Name );
            }
        }

I don't know if there are other reasons for this impl, but PropertyChanged(this, null); is intended to serve the purpose of notifying that all properties for the object have changed.

I didn't know that, good tip!

That OnPropertyChanged is called in multiple places isn't weird, the fact that there are multiple types of properties (fields and navigators) and that in different situations properties can be 'rolled back to a previous value', requires that the event has to be raised.

INotifyPropertyChanging is an interface you should implement in a partial class of CommonEntityBase, a generated class for extending all entities (it's in the generated code). You then also override in that same class the method OnSetValue, for field sets

Note: this can lead to false positives, e.g. when the value wasn't changed at all due to validation restrictions. That's due to the interface: the interface is rather weird, because the act that a property changes is atomic. This means that the interface notifies that something is changing, but that 'changing' hasn't yet started. The set action itself is atomic and then the change is notified again.

I therefore don't really see why you need the interface, as IMHO it doesn't really add something valuable or how it would make you work more efficiently, as the atomic action isn't interceptable anyway.

I understood the purpose for the other OnPropertyChanged's, that's just one reason why I decided against modifying EntityBase2 directly.

I agree INotifyPropertyChanging seems extraneous, there just happens to be some magic that makes CLINQ change monitoring more efficient if its present.

I don't see any way I can reliably add INotifyPropertyChanging with this partial classes etc. It would have to be baked in. I think I'll ask the CLINQ author what the real impact is.

tmatelich wrote:

I understood the purpose for the other OnPropertyChanged's, that's just one reason why I decided against modifying EntityBase2 directly.

I agree INotifyPropertyChanging seems extraneous, there just happens to be some magic that makes CLINQ change monitoring more efficient if its present.

I don't see any way I can reliably add INotifyPropertyChanging with this partial classes etc. It would have to be baked in. I think I'll ask the CLINQ author what the real impact is.

If you do as I described above, you at least will get the call to OnSetValue every time a field value is attempted to be set, BEFORE the value is set. (so in the 'changing process').

If you need info from us for the CLINQ author, please let me know.

Explanation of the value of INotifyPropertyChanging provided. Still waiting on info regarding the effect of a Changing without a corresponding Changed:

http://clinq.codeplex.com/Thread/View.aspx?ThreadId=76230

I keep bouncing back and forth on whether I think SelectMany will save me time and effort or not, but I don't think I'm working with the quantity of entities at any given time to make a serious impact.