Right now, when my users click enter, or fill out parts of the rows by clicking in them, the new row appears.
However, I have given them a button to select items to fill out the grid. When I fill out the cell values for that row, NOTHING I call, even grid execute commands will force that new row to appear. The only way it will appear is if they click in the cell and hit enter...
I find this extremely annoying. I know I've seen a lot about binding list <T>, but for God's sakes there should be something that's easily callable that says I am done with this row, commit and move the new row below. AM I MISSING SOMETHING???
Hello,
You are right, I am going to bring this up to the Development team and will let you know when I have more information on this matter.
I know they just gave me a new build for a legit bug that I'd found, but do you think they could call this a "bug" and roll out another version? If you hear of any work around please let me know, I am certain I am going to get negative feedback on this from my customers...
I asked the developers. They said that this is the expected behavior. The Add New is not invoked until the users enter edit mode. We do not want to create this underlying object when you set values because you could be just initializing the template add record.
I am still waiting for response from them for any way around this. Meanwhile, you can consider invoking AddNew of the underlying data source to create a new row and chage its values.
Right, so if that's the case then why is it if I call the command (I forget the method) to enter edit mode and end edit mode the new record is not created -- because I have actually attempted to do this as well just to force the new record to show.
Yes, please let me know of a work around.
Here's some code I've tried as an example:
grdPartsUsed.ExecuteCommand(DataPresenterCommands.StartEditMode); grdPartsUsed.ActiveCell = dr.Cells["Code"];
dr.SetCellValue(dr.FieldLayout.Fields["Code"], item.Code, false); dr.SetCellValue(dr.FieldLayout.Fields["Per"], item.Per, false); dr.SetCellValue(dr.FieldLayout.Fields["Description"], item.Description, false); grdPartsUsed.ExecuteCommand(DataPresenterCommands.EndEditModeAndAcceptChanges);
I'm sure this problem has arisen because we're not writing our own custom classes and just passing in the SQLMetal generated list of a class (actually a table object) (in this case List of UsedParts)-- but still, IMHO, there should be a way to emulate the user behavior of editing a cell that causes the new row to appear.
Another poster and I have had lengthy discussions about this issue and it being related to our SQLMetal generated classes, but shouldn't these grids play nice with SQLMetal and if not at least give people who want to generate their ORM through SQLMetal a work around? Sorry to lecture here, just spent way more time on this than I should have!!!!!!
The thing is -- SQLMetal helped us develop very rapidly and I think this will be the way to go in the future so I would think for a lot of future apps sense time is usually of the essence.
We are currently discussing this. I will be updating you on the progress of this issue through the support case.
Alex can you please check into this -- this is considered a show stopper for our app because the users perceive it as the grid "dropping" items. This is critical, please respond ASAP.
The problem is not in the underlying data source/ classes. I have tried this with custom class and this is by design. I am going to create a support case on your behalf for this issue. We will continue this discussion there.