Ticket S35126
Visible to All Users

SystemModules.Win - Make it possible to edit multiple records in an editable ListView at once and save the changes only when needed

created 15 years ago

Currently, as a workaround in WinForms you can use the following ViewController:

C#
namespace MainDemo.Module.Win { public class S35126 : DevExpress.ExpressApp.Win.SystemModule.WinDetailViewController { protected override void OnActivated() { base.OnActivated(); SuppressConfirmation = IsBatchUpdateEnabled(); } protected override void OnViewQueryCanChangeCurrentObject(System.ComponentModel.CancelEventArgs e) { if (IsBatchUpdateEnabled()) return; base.OnViewQueryCanChangeCurrentObject(e); } private bool IsBatchUpdateEnabled() { return View.Id == "DemoTask_ListView"; } }

As for the Web, you can consider implementing solutions from the following articles:
ASP ListView edit all lines at once
How to edit multiple selected rows in a single Edit Form
You can also consider embedding a custom user control based on a pure ASPxGridView into an XAF View as described at How to show custom forms and controls in XAF (Example).
See Also:
How to disable an automatic saving when changing the row in an editable list view
BatchEntry - Support for massive manual data entry (Batch Entry)
Proposed Solution:
By default, in an editable ListView if I edit a record and then move to the next record, the annoying confirmation message is displayed. It makes it impossible to edit multiple records and fields in the grid at once.
Currently, I can only enable automatic saving using the WinDetailViewController.AutoCommitListView = True but this way the Save buttons won't be available.
If I don't touch the AutoCommitListView property and just set the WinDetailViewController.SuppressConfirmation = True, then I will be able to edit only a single record and then save the changes. I can't edit multiple records this way because if I move to the next record my previous changes will be lost.
So, it would be good to have the capability to edit multiple records and disable the annoying confirmation message when moving between records. To save multiple changes, I would use the Save buttons when needed. However, the confirmation message should be displayed if I go to another View.

Answers approved by DevExpress Support

created 12 years ago (modified 9 years ago)

We have implemented the functionality described in this ticket. It will be included in our next update(s).

Please check back and leave a comment to this response to let us know whether or not this solution addresses your concerns.

Additional information:

Set the ModificationsController.ModificationsCheckingMode to OnCloseOnly to commit modifications only when the current View is closed. Changes will not be committed and confirmation will not be displayed when a user proceeds to the next record in the editable List View.

    Show previous comments (9)

      This new default setting will bite you when you use TabbedMDI in existing applications - as it did bite me (and my users)!

      Dennis Garavsky (DevExpress) 11 years ago

        @Willem: I would highly appreciate it if you could log a separate ticket and describe your scenario and the problematic behavior in detail. Thanks.

        Anatol (DevExpress) 10 years ago
          created 12 years ago (modified 12 years ago)

          Hi Dennis,

          That's really useful thanks! I was playing around with the AutoCommitListView option, but my manager said (quite rightly really) "what if the user makes a mistake in a list and changes something by accident?"

          The only problem with your code above is that if the listview (or the whole app) is closed with pending changes then they're lost without warning. So I worked up a little solution to that by looking at how the standard WinDetailViewController handles the save confirmations, and my result is below.

          Confirmations are suppressed until the view is about to be closed, then the usual "Do you want to save" will be asked if there are any pending changes.

          It would be great if a "batch update mode" setting could be made a standard property in the application model to enable this feature without the custom code.

          Anyway here is my version, I hope someone will find it useful.

          C#
          using System.ComponentModel; using DevExpress.ExpressApp; using DevExpress.ExpressApp.Win; using DevExpress.ExpressApp.Win.SystemModule; namespace BWM.Module.Win.Controllers { public partial class ListViewBatchUpdateController : WinDetailViewController { protected override void OnActivated() { base.OnActivated(); SuppressConfirmation = IsBatchUpdateEnabled(); } protected override void OnViewQueryCanChangeCurrentObject(CancelEventArgs e) { if (SuppressConfirmation) return; base.OnViewQueryCanChangeCurrentObject(e); } protected override void OnViewQueryCanClose(CancelEventArgs e) { if (SuppressConfirmation && !e.Cancel && ObjectSpace.IsModified && !AutoCommitListView) { var winWindow = base.Frame as WinWindow; if (winWindow != null && winWindow.Form != null) winWindow.Form.Activate(); var confirmationResult = Application.AskConfirmation(ConfirmationType.NeedSaveChanges); if (confirmationResult == ConfirmationResult.Yes) { ObjectSpace.CommitChanges(); } else if (confirmationResult == ConfirmationResult.Cancel) { e.Cancel = true; } } } private bool IsBatchUpdateEnabled() { if (AutoCommitListView) return false; // Customise whatever views you want to enable batch update for here. return View.Id == "IDB_Lookups_ListView"; } } }
            Show previous comments (3)
            Dennis Garavsky (DevExpress) 12 years ago

              Nick,
              Thanks for the update. I somehow also missed this small, but very important detail. I have updated your code to remove the constructor.
              I would be more than happy to blog about how this works internally, if this had not already been described in our docs at:

              1. http://documentation.devexpress.com/#Xaf/CustomDocument2727
              2. http://documentation.devexpress.com/#Xaf/CustomDocument2676
                While we are at it, I think that you will be excited to know that this functionality can be enabled via a single option in the next major XAF version. So, please stay tuned!

                Hi Dennis, thanks for fixing that!
                The docs certainly imply that an inherited controller replaces the base type, but unless I missed something they don't go into detail about how the inherited controller gets instantiated, and what then happens to the base controller… if it is still activated at all, or totally replaced etc.
                As I've been learning XAF I've found some of these "behind the scenes" processes a little hard to get my head around, so more details are always welcome.
                Looking forward to the 13.1 release!

                DevExpress Support Team 12 years ago

                  Hi, Nick. These specifics are not described in our docs as they are not directly related to XAF. Controllers are regular .NET objects which are polymorphic. Since XAF application instantiates all the Controllers that do not have descendants, your base Controller type will not be directly instantiated. However, all the functionality implemented in the base Controller will be active unless you override it in a descendant Controller.

                  Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

                  Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.