Hi,
we have a problem using your ListViewAutoCommitController.
The commit behaviour is generally fine, but we ran into some issues in conjunction with using actions.
In detail, we have an action that is registered on ObjectSpace.ModifiedChanged event. This action gets enabled or disabled
depending on ObjectSpace.IsModified value.
Editing a cell value and clicking the action would trigger the commit, but raises also the error 1007: cannot execute inactive or disabled action.
Afterwards the action is drawn as disabled, which is correct.
It seems that the standard save action also shows this behaviour in this scenario.
Can you help us to prevent this error? The behaviour is ok but it would be nice to allow clicking and ignoring this error somehow.
Attached is a sample project that represents this scenario.
To reproduce the error, you need the following steps:
- Open the Country_ListView with navigation menu entry 'Country'. The view should be in ListAndDetail mode.
- Create a Country and a child Bank object and save.
- Edit the 'Bank' object directly in the nested ListView of 'Country' and click the action 'Some Action' (located in nested ListView menu bar).
Alternatively you could try the save action, which should trigger the same error.
Feel free to ask if you need further explanation.
Greetings, Kim Schmidt
Hi Kim,
The ListViewAutoCommitController was not designed to operate in this scenario. The issue occurs because you forcibly enable this controller in a nested list view. When you are clicking your action button after modifying an object in a nested list view, the grid closes an in-place editor and modifies the object. Then, ListViewAutoCommitController commits changes and your code disables the action. So, your action becomes disabled just before action execution. I suggest that you do not enable ListViewAutoCommitController for nested list views.
Thanks,
Michael.
Hi Michael,
thanks for your reply.
The same problem occurs for root list views when using the sample action and in-grid-editing (ListViewAutoCommitController has been replaced by ViewController<ListView>.
But the save action now works just fine. How does the save action work in this scenario, where is the difference? Is there a way to rewrite our action to behave similar regarding enabled/disabled status?
For clarification I've attached an updated sample.
Greetings, Kim Schmidt
Hi Kim,
In the updated project, when a grid row is modified and the grid loses focus, a confirmation dialog is shown (if auto-commit is disabled). After you close the confirmation dialog, all changes in the object space are discarded by either committing or canceling. The confirmation and commitment is intentionally suppressed for specific actions (Save, SaveAndNew, SaveAndClose, Cancel) by WinDetailViewController. I recommend that you deactivate your action for root list views, because when it comes to action execution, there are no uncommitted changes.
Thanks,
Michael.
Hello,
I have found a workaround that works for me. I have written a BarSimpleButtonItem derivation and made my own implementation of the ItemClicked method. In this implementation I make sure that action.DoExecute is only called if the action is enabled!
else if (Action is SimpleAction && Action.Enabled)
{
((SimpleAction)Action).DoExecute();
}
The problem in our case is, that the call of BindingHelper.EndCurrentEdit in this Method (its in the first line… base.ItemClicked) triggers a event in which we commit! Because the ObjectSpace is commited… the action that should be executed (in our case the save-action) by the click is disabled.
It would be nice, if you could add just the check "Action.Enabled" in your sources… than I could remove my derivation. Is that possible?
Thank you very much
Kim
Hi Kim,
I am afraid I do not understand why you need this workaround and why you cannot deactivate your action in root list views. If there is a real-life scenario that our framework cannot handle because of this issue, please explain it in greater detail.
Thanks,
Michael.
Hello Michael,
forget about the last example we attached… we made this one only to show the error. Our real-life scenario is, that we want to enabled autocommit in nestedListViews. We know that the DetailView uses the same objectSpace and will be commited as well… that no problem. The problem is, that if you are editing something in the nestedListView and now you want to press the save button (the save action is active, because you are editing something in the listView) the following things will happen in this order:
As you can see, in our case the EndCurrentEdit event (which is triggered first) deactivates the saveAction that is called a few lines later. I think a check if the action can still be executed will be an improvement!?
Thank you in advance
Best regards
Kim
Hi Kim,
Thank you for the clarification. Your scenario looks rather strange. If you enable auto-commit, changes are committed automatically and there is no need for Save and Cancel actions. You should deactivate them as we do this in our WinDetailViewController. I do not understand why you leave them active.
Thanks,
Michael.
Hi,
the save action is needed, because you can edit in the detailView and for the detailView autocommit should be inactive. The AutoCommit is only active if you are editing in the nestedListView.
Maybe I got to add that the first View in which we need this feature is a MasterDetail View. We got a listView on the left side… and the corresponding editView (DetailView). This DetailView has a lot of nestedListViews… in these views the user will add thousands of objects. It's important to save after editing and so we need the autoCommit feature only in these nestedListViews. That's the concept our product managers and customers want.
Thank you
Kim
Hi Kim,
Thank you for the additional information. We are working on your issue and will answer you as soon as possible. We are sorry for the delay.
Thanks,
Michael.
Hi Kim,
>>>the save action is needed, because you can edit in the detailView and for the detailView auto-commit should be inactive. The AutoCommit is only active if you are editing in the nestedListView.
Remember that both detail and list views exist in the same object space. So, changes of the entire object tree are committed even if you call the CommitChanges method from any nested list view. Why not to trigger auto-commit for detail views too and deactivate the Save action?
We will not suppress the exception in order not to introduce a breaking change. This exception notifies the developer about a problem in his/her controller logic.
If you still want to show the Save button when auto-commit is enabled, deactivate the built-in Save action and create a custom Save action that does not depend on the ObjectSpace.Modified property value and is always active.
Thanks,
Michael.