I saw that when you set a related entity property (1:1 relation) to an entity, you don't raise a PropertyChanged event as you do for simple property (string, int, ...). Is there a particular reason why you don't implement it ? Ex : IncidentEntity incident = new IncidentEntity(); incident.Vehicle = new VehicleEntity(); => I'm interesting to be inform when the Vehicle property has changed.

PropertyChanged is an event meant for bound UI controls, i.o.w. a databinding event

The following events exist in LLBLGen Pro 2.0: OnRelatedEntitySet and OnRelatedEntityUnset

Please refer to: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=6828

Yes I saw this thread but this force me to inherit from my entity (IncidentEntity). I think an event is more convenient and don't really understand the real reason you don't raise this event.

Why don't you generate by default in the template an VehicleChanged event (according to my example) ?

Sylvain wrote:

Yes I saw this thread but this force me to inherit from my entity (IncidentEntity). I think an event is more convenient and don't really understand the real reason you don't raise this event.

Why don't you generate by default in the template an VehicleChanged event (according to my example) ?

VehicleChanged as in: 'Vehicle' is the related entity? Nice suggestion. I'll look into that. One can't have both _field_Changed and PropertyChanged events in one class unfortunately, as winforms databinding will then fail, so either one of them has to be chosen.

Otis wrote:

Sylvain wrote:

Yes I saw this thread but this force me to inherit from my entity (IncidentEntity). I think an event is more convenient and don't really understand the real reason you don't raise this event.

Why don't you generate by default in the template an VehicleChanged event (according to my example) ?

VehicleChanged as in: 'Vehicle' is the related entity? Nice suggestion. I'll look into that. One can't have both _field_Changed and PropertyChanged events in one class unfortunately, as winforms databinding will then fail, so either one of them has to be chosen.

Although mainly used for data binding fields, I see the new-style PropertyChanged event as representing _any _property change. The name of the property changed is passed in the PropertyName property of PropertyChangedEventArgs (or null or string.Empty to indicate all fields may have changed) so there is no confusion over what has changed - "Vehicle" in this case - easy to check against and type safe if you compare against xxxFields.Vehicle.Name.

Cheers Simon

Clever thinking, I think that's indeed a much better approach. Thanks for the insight

Thanks for your quick answer.