I have an UltraGrid on a Windows form. This grid is hierarchical and is bound to a BindingSource which is bound to an EntityCollection (Entity Framework). This hierarchy is made up of people and addresses as follows:
Person 1
-> Address 1
-> Address 2
Person 2
Each set of addresses has a new row template available at the bottom for adding additional addresses. When I first enter the new row to add an address, a new address entity is created with an EntityState of Detached. If I tab to the next row, the EntityState is changed to Added. This is the proper behavior.
The problem is that if I use this new row to add an additional address and then click to another band instead of tabbing to the next row, the EntityState remains as detached and does not get saved to the database. Additionally, if I click back to the original address band, the address I just added disappears.
For example:
I add an address to a person...
Doe John
-> 123 Main Street (... I press tab to move to the next line and add a second address ...)
-> 456 Central Ave (... Instead of tabbing to the next line, I click to the addresses of another person ...).
Doe Jane
-> 789 Washington Ave (... Here.)
... If I then click back to the addresses for John Doe, the 456 Central Ave address disappears because I never tabbed off of that line.
How do I prevent this behavior.
What, exactly, do you mean when you say "click on another band?"
Any action that causes focus to leave the current row and move to another row is essentially the same as far as the grid is concerned. In fact, the grid doesn't even really do much in either case. All it really does it change the Position on the BindingManager. This causes the BindingManager to call EndCurrentEdit, but the grid doesn't even do this directly.
The type of data source you are doesn't matter as far as that behavior goes.
So if you are clicking on any other row in the grid, then there should not be a problem, unless the DotNet Framework is specifically behaving differently with the EntityFramework.
If you click outside of the grid, then that's a different story. The UpdateMode property of the grid determines what happens in that case, and by default, the grid behaves the same way when it loses focus. But if you are clicking on something like a toolbar button, which doesn't take focus away from the grid, then the grid would not commit that last edited row and that might be causing a problem here.
If you want to try to work around the issue, you could try trapping Before/AfterRowDeactivate and explicitly calling grid.UpdateData to commit all changes in the grid.
Beyond that, though, I think we'd need to see a sample project demonstrating the issue in order to tell you what's going on there for sure.
Mike,
As you can see in that link I provided, the position not being changed is exactly what seems to be causing this behavior. I've tried calling UpdateData() as well as PerformAction(CommitRow), but neither of those options work.
Changing the position in the BindingManager does something that causes the new object to have its EntityState changed from Detached to Added. Since the only data source I set is for the top-level rows / band, and the data sources for child bands are created dynamically, the binding manager for those child bands does not seem to be accessible to my code.
Well, the only workaround I could come up with was to create a custom class that inherits from the UltraDataSource. I then provided methods in this class to interact with the entity context, handling creating, updating, and deleting the objects. Therefore, I grid has no direct interaction with the entity context - I control it all through the UltraDataSource. This required a great deal of extra code and should not be necessary, but it does work.
Mike, in response to your last message...yes, I did try using a BindingSource, as I stated in my original post, second sentence. I tried calling the UpdateData() method from several places, including directly when the Save button was clicked.
This same issue was reported back in 2010. I found posts all the way back to 2008 of people reporting issues when using the grid with the Entity Framework. Since Entity Framework is now on version 6 and seems to be where Microsoft is putting all of their effort (they aren't developing datasets any longer), perhaps you should start testing to make sure your controls work well with it.
Hello,
I have opened a private case for you so that I can link it to an internal development issue. This way you will be notified automatically when a development issue is updated. The case number is CAS-135456-N1Q7H4. You will see it located here: https://www.infragistics.com/my-account/support-activity
Let me know if you have any questions regarding this matter.
Thank you.
Hell Jacob,
This has been addressed in service release version of WinForms_14.1.20141.2059. Have you had time to review if this fixes and do you have any additional questions at this time?
I'm sorry, but this does not fix the problem. I used the same sample I originally uploaded to test and the same problem persists.
Hello Jacob,
I updated to the latest service release available and I was able to access the child row unlike before. The parent row is now committed and the child row no longer disappears when I enter it.
Please make sure that your application is referencing the updated assemblies. You can view them within Visual Studio through the Solution Explorer > References > right-click choose Properties > Version
After I updated I immediatly updated the project using the version utility. The version utility is accessible by choosing Tools > Update Infragistics Version 14.1 within Visual Studio.
Let me know if you have any questions.
I tried to upload a video showing the issue and showing that I am using the updated version of 2014.1. However, the upload function is not working for me.
Ok, after reviewing the sample again I noticed the behavior occurs across child rows of different bands. However I like to mention that patch does not fix this. There was an issue with the way the parent row was is committed. Now when clicking a sibling/add new row in the same band the parent row no longer disappears.
If you click a row higher up or across a band all together then that row is still not committed.
To address this behavior you are going to be required to handle the BeforeRowDeactivate event and call PerformAction on your grid to commit the row.
Private Sub UltraGrid1_BeforeRowDeactivate(sender As Object, e As System.ComponentModel.CancelEventArgs) Handles UltraGrid1.BeforeRowDeactivate With UltraGrid1 .PerformAction(Infragistics.Win.UltraWinGrid.UltraGridAction.CommitRow) '.Update() //Optional End With End Sub
Private Sub UltraGrid1_BeforeRowDeactivate(sender As Object, e As System.ComponentModel.CancelEventArgs) Handles UltraGrid1.BeforeRowDeactivate
With UltraGrid1
.PerformAction(Infragistics.Win.UltraWinGrid.UltraGridAction.CommitRow)
'.Update() //Optional
End With
End Sub
This does seem to fix the issue. Thank you.
There is a minor user interface penalty because the user now needs to double click to move to a sibling row within the same band. It must be a side effect of calling CommitRow.