Symptoms
We are developing an application using SmartForms.
During user's tests, we noticed a very annoying bug on list type views.
If we have an editable list view based on a SmartObject with existing data, we select an existing row and try to add a new row, we enter edit mode on the new row but the selection still remains highlighted on the previous selected row. Then, if we click on the "Delete" button, the new row AND the previous selected row are deleted.
We noticed the bug appears only if there is data when initializing the view. If there is no data at loading and if we create several rows at first, the selection "unselects" or stops being highlighted when we create a new row.
Here are the steps to recreate the bug:
- Create a View with type "List view"
- Set the data source with a SmartObject (smoUsers in our example) based on a SQL Server table
- Enable "List editing" and "Add new row link"
- Add a btnDelete toolbar button
- Create several rules :
* When the view execute Initialize :
Then execute the List method
* When the view executed List item added :
Then apply the changes made to the row
* When the view executed List item changed :
Then apply the changes made to the row on the editable list
* When the view executed List item double click :
Then edit the selected row on the editable list
* When the view executed List item removed :
Then apply the changes made to the row on the editable list
* When btnDelete is Clicked :
Then cancel the changes made to the row on the editable list (for new row case)
Then remove the selected row from the editable list (for existing row case)
Keep in mind most of the above rules are created by default when the View is auto-generated, however the last rule needs to customised.
Diagnoses
Reproducible in Denallix VM
Resolution
TFS item was logged.
A possible workaround I just thought would be to check the status of the row we want to delete in the "Delete button click" rule :
- If it's a brand new row, we only execute the "Cancel the changes made to the row on the editable list" rule
- If it's an existing row in read mode, we only execute the "Remove the selected row from the editable list" rule
- If it's an existing row in edit mode, we execute the "Cancel the changes made to the row on the editable list" rule and the "Remove the selected row from the editable list" rule
I just tried to set that workaround up by doing this :
I added a parameter named isEditMode to know if we are in edit mode or not.
I set it to TRUE in the "When the View executed List item double click" and in the "When the view executed List row added" rules.
I set it to FALSE in the "When the View executed List item added" and in the "When the View executed List item changed" rules.
I also added a parameter named isNewRow to know if it's a new row or not.
I set it to TRUE in the "When the view executed List row added" rule.
I set it to FALSE in the "When the View executed List item added" and in the "When the View executed List item changed" rules.
In the "When Delete button is clicked" :
- if isEditMode = FALSE and isNewRow = FALSE
* Remove the selected row
-if isEditMode = TRUE and isNewRow = TRUE
* Cancel the changes made to the row
- if isEditMode = TRUE and isNewRow = FALSE
* Cancel the changes made to the row
* Remove the selected row
- Data transfer to set isEditMode and isNewRow to FALSE
After some tests, it seems to work properly in each case.
