I apologize in advance for including two feature changes in the same PR :)
The name of the type parameter in the generated extensions methods was called 'source', the generated proxy classes would not compile if any of the actions or functions on the service had a parameter also named 'source'. This was resolved by renaming the hardcoded extension type parameter to '_source'.
This change was implemented in both C# template and VB.
An alternate implementation for INotifyPropertyChanged has been added, along with a tickbox in the advanced settings dialog to toggle the implementation.
This setting is only visible IF the Enable entity and property tracking setting is enabled.
This setting is only enabled for C# code generation at this point in time.
The basic scenario that this solves is that now when you have async logic that updates properties that are bound to the UI, you do not have to worry about thread marshalling issues.
One simple proof is to bind a Collection from an OData response to a grid, then add a new row to the collection, then execute SaveChangesAsync on the context/container. If the service returns an object with any modified fields, usually the auto-assigned Key field or other default values for properties then when these values are applied back to the object that is bound to the new row, the app will crash with a cross-thread marshalling exception.
I apologize in advance for including two feature changes in the same PR :)
The name of the type parameter in the generated extensions methods was called 'source', the generated proxy classes would not compile if any of the actions or functions on the service had a parameter also named 'source'. This was resolved by renaming the hardcoded extension type parameter to '_source'.
An alternate implementation for INotifyPropertyChanged has been added, along with a tickbox in the advanced settings dialog to toggle the implementation.
Enable entity and property trackingsetting is enabled.The implementation is a blatant rip off from this Stack Overflow response: https://stackoverflow.com/a/45422891/1690217
The basic scenario that this solves is that now when you have async logic that updates properties that are bound to the UI, you do not have to worry about thread marshalling issues.
One simple proof is to bind a Collection from an OData response to a grid, then add a new row to the collection, then execute
SaveChangesAsyncon the context/container. If the service returns an object with any modified fields, usually the auto-assigned Key field or other default values for properties then when these values are applied back to the object that is bound to the new row, the app will crash with a cross-thread marshalling exception.