Hi,

When I enter a new row in the UltraWingrid that is binded to an EntityCollection (a detail-collection for an entity, ProductPacking as detail for Product), a new Entity is added to the collection. That entity is marked as 'Dirty', because the FK (ProductId) is changed. When I now leave the grid without pressing ESC, I want to cancel the insert of the entity (that should fail, because other required fields are empty). In the users opinion, there's no change. He only selected the new row (pressing tab from the last cell in the previous row), and wouldn't enter another one.

What's the best way to do that without asking the user to press ESC twice?

Thanx, Bert

Before you call SaveMulti() I would check the last entity in the collection and remove it if the data is invalid.

bclubb wrote:

Before you call SaveMulti() I would check the last entity in the collection and remove it if the data is invalid.

What you might want to do is place that type of logic in your bl.

Ok, it's clear to me that I've to check in code if I can delete the new entity. The entity can automatically be deleted when (in the example) only ProductPacking.ProductId was changed. Now I'm looking for a way to achieve this from a template, because I don't like to write this code manually for each entity. But when generating this sort of code, I think I can only check if it is a FK, but there can be more FK's in the entity

BertS wrote:

Ok, it's clear to me that I've to check in code if I can delete the new entity. The entity can automatically be deleted when (in the example) only ProductPacking.ProductId was changed. Now I'm looking for a way to achieve this from a template, because I don't like to write this code manually for each entity. But when generating this sort of code, I think I can only check if it is a FK, but there can be more FK's in the entity

What logic you exactly need, because it might very well be possible to create it with the current crop of TDL statements

Btw: if you call CancelEdit() on the last entity in the collection, it will remove itself from the collection if it's not a finalized edit. So that's the same action as when the user pressed ESC.

Hey BertS,

Any chance you can post a sample of your code where you bin UWG to a collection class? I got the basics of this down, but am challenged by the more complicated aspects of this including paging, editing, etc.

Thanks,

Wingnut wrote:

Hey BertS,

Any chance you can post a sample of your code where you bin UWG to a collection class? I got the basics of this down, but am challenged by the more complicated aspects of this including paging, editing, etc.

Thanks,

Hi,

I'm using the Wingrid, not the Webgrid. Databinding: myGrid.SetDataBinding(_collection, "", true, true)

Otis wrote:

BertS wrote:

...

What logic you exactly need, because it might very well be possible to create it with the current crop of TDL statements

Something like this:

For Each field In entitityfields
  if field.IsDirty AndAlso field.Name <> "ProductId" then countChanged += 1
Next fld

If countChanged=0 Then Me.CancelEdit()

The problem I think is to identify which field should be skipped (in this case ProductId). It's always a FK-field, but it's not for each FK-field in the fields-collection. Also, there's not for each entity such an parententity For example: ProductEntity doesn't have a parent, but it has FK's lyke ProductTypeId, and ProductPackingEntity has the parent ProductId and another FK PackingTypeId In Product, no field is excluded from the countChanged, and in ProductPacking, the field ProductId should be excluded. So: how can I identify this? Maybe using a custom property on the entity, should be possible (this is just coming up now into my thoughts )

Btw: if you call CancelEdit() on the last entity in the collection, it will remove itself from the collection if it's not a finalized edit. So that's the same action as when the user pressed ESC.

I know, but if the user has changed one or more fields and not committed the entity (row), then CancelEdit should not be used, but the entity should be validated and saved (if possible).

How do you have a user commit their changes? And what does the code for your commit look like?

bclubb wrote:

How do you have a user commit their changes? And what does the code for your commit look like?

Changes are committed when they leave the row in the grid (or click the Save-button or close the form, which both call a Save(recursive:true) on the parent-entity)

Ok, it seems that I've solved it by Adding a new function to the entityBase class:

Public Function IsDirtyEntity() As Boolean
    If Not Me.IsNew Then Return Me.IsDirty
    If Not Me.IsDirty Then Return False

    ' Set a variable with the name of the ParentEntityKey-fields, a custom-property for the entity
    Dim parentEntityKeyField As String = ""
    If Me.CustomProperties.Contains("ParentEntityKey") Then
        parentEntityKeyField = CType(Me.CustomProperties("ParentEntityKey"), String)
    End If

    Dim countChanged As Int32 = 0
<[Foreach EntityField CrLf]>            If parentEntityKeyField <> "<[EntityFieldName]>" AndAlso Me.Fields("<[EntityFieldName]>").IsChanged Then countChanged += 1<[NextForeach]>

    If countChanged = 0 Then
        Me.CancelEdit()
        Return False
    Else
        Return True
    End If
End Function

Which produces in the scenario with Product/Productpacking for the ProductPacking:

Public Function IsDirtyEntity() As Boolean
    If Not Me.IsNew Then Return Me.IsDirty
    If Not Me.IsDirty Then Return False

    ' Set a variable with the name of the ParentEntityKey-fields, a custom-property for the entity
    Dim parentEntityKeyField As String = ""
    If Me.CustomProperties.Contains("ParentEntityKey") Then
        parentEntityKeyField = CType(Me.CustomProperties("ParentEntityKey"), String)
    End If

    Dim countChanged As Int32 = 0
    If parentEntityKeyField <> "Id" AndAlso Me.Fields("Id").IsChanged Then countChanged += 1
    If parentEntityKeyField <> "ProductId" AndAlso Me.Fields("ProductId").IsChanged Then countChanged += 1
    If parentEntityKeyField <> "Title" AndAlso Me.Fields("Title").IsChanged Then countChanged += 1
    If parentEntityKeyField <> "GrossUnity" AndAlso Me.Fields("GrossUnity").IsChanged Then countChanged += 1
    If parentEntityKeyField <> "NetUnity" AndAlso Me.Fields("NetUnity").IsChanged Then countChanged += 1

    If countChanged = 0 Then
        Me.CancelEdit()
        Return False
    Else
        Return True
    End If
End Function

The custom property is set to ProductId. So, if only ProductId was changed and no other fields, I cancel the new entity.

When validation an entity, I call this function: If Not MyBase.IsDiryEntity Then Return True

IsDirty should already reflect this, if a field is changed, IsDirty is true, otherwise false. I've to look into this deeper to understand why in your case it's not working.

You can safely call CancelEdit() on an entity which edit cycle is finished, as it's then a no-op. For the entity on the last row, which is new and which you want to get rid of, this isn't the case: it has an edit cycle running. Calling CancelEdit() on that entity, will make it check its internal property to see if it's been added by databinding. If so, it removes itself.

Otis wrote:

IsDirty should already reflect this, if a field is changed, IsDirty is true, otherwise false. I've to look into this deeper to understand why in your case it's not working.

My tests showed that ProductPackingEntity.ProductId is dirty (which makes the whole Entity dirty). I think it is because it's set by adding a new entity to Product.ProductPacking(collection)? (it's the FK-field for the relation). Maybe it's caused by UltraWinGrid...

Maybe the entity should be deleted automatically, but then my validation-procedure is running before your internal check. (I validate an entity in this collection when leaving the row or the grid, and it's saved (recursive) from the parent)

BertS wrote:

Otis wrote:

IsDirty should already reflect this, if a field is changed, IsDirty is true, otherwise false. I've to look into this deeper to understand why in your case it's not working.

My tests showed that ProductPackingEntity.ProductId is dirty (which makes the whole Entity dirty). I think it is because it's set by adding a new entity to Product.ProductPacking(collection)? (it's the FK-field for the relation). Maybe it's caused by UltraWinGrid...

Ah, yes, the FK is set through syncing. Should have thought about that...

Otis wrote:

Ah, yes, the FK is set through syncing. Should have thought about that...

Ok, glad to see that you understand the behaviour Above you can see how I solved this now, but maybe there's another way to do/solve this?

BertS wrote:

Otis wrote:

Ah, yes, the FK is set through syncing. Should have thought about that...

Ok, glad to see that you understand the behaviour Above you can see how I solved this now, but maybe there's another way to do/solve this?

Not that I can think of...

What I was thinking about: maybe you can change the behaviour from your framework, so that the setting of that FK-field (when adding an entity to a collection) doesn't affect the IsDirty?

BertS wrote:

What I was thinking about: maybe you can change the behaviour from your framework, so that the setting of that FK-field (when adding an entity to a collection) doesn't affect the IsDirty?

That's not what you want, as it won't save the FK side in a recursive save if no other fields are changed

Otis wrote:

BertS wrote:

What I was thinking about: maybe you can change the behaviour from your framework, so that the setting of that FK-field (when adding an entity to a collection) doesn't affect the IsDirty?

That's not what you want, as it won't save the FK side in a recursive save if no other fields are changed

Maybe you've to re-read this thread, because thats exactly what I want (and what I've created in my own code now). But it should not be for each FK, but only for the FK that holds the relation with the parent-entity to which the child is added.

Edit: ok, I think this functionality should be optional, because it may not always be the wanted behaviour