Hi Devexpress Support
I today got aware of a glitch in the Event Editor. As I edited an event my colleague was also editing at the same time , I was not able to save the event because of his modifications (showing the db info dialog 'some data was modified'; absolutely correct).
But hitting the cancel button on my Event Dialog brings up the 'do you want to save…' confirmation, therefore I went for the 'No' button. But even the 'No' button raises the 'some data was modified' dialog, which is wrong, as no data should be persisted to the db. So I had no way to close the Event Dialog.
[The only way to close the dialog is to use the dialogs X button .]
Please change the Cancel/No button behavior to correctly close the dialog. (In my opinion, it's even not necessary to ask 'Do you want to save changes?' on hitting the 'Cancel' button on the Event Editor Dialog, but at least the 'No' answer should close the dialog.)
Many thanks for an update.
Kind regards
Jonas
Hello Jonas,
I am not sure that I correctly understand your scenario. The point is that our Scheduler has nothing special to process multi-user conflicts. This kind of "protection" is supposed to be implemented at the database level. For example, if someone is editing an event, it should be impossible for someone else to start editing. Otherwise, data will become invalid. Thus, it is unclear what you want us to fix. Would you please provide us with a small video demonstrating what happens with the event dialog in your scenario?
Dear Paulo
I absolutely understand the underlying database behavior. I just miss the proper GUI logics.
The code I'm looking into:
cxSchedulerEventEditor:
Line 886:
procedure TcxSchedulerEventEditorFormHelper.Cancel(var AModalResult: TModalResult);
begin
if CanClose then
begin
Event.Cancel;
FModified := False;
Storage.FullRefresh; // here bevore I'm missing to cancel the pending recordset -> Recordset.CancelUpdate;
Close(AModalResult);
end
else
AModalResult := mrNone;
end;
On line 892, there is missing first to cancel the already altered recordset. And yes, I know you have no access to the recordset there.
So I'm looking for the 'workaround' solution.
My only goal: If the user presses 'Cancel' the dialog MUST be canceled at all costs!
Attached my example.
Run it twice and edit at the same time the same event.
The first attempt you can save properly.
The second attempt (on the 'other' application) you can't save properly, as the database denies this.
Therefore you confirm the error and go for 'Cancel'.
Now your dialog comes up asking to save again, go for 'No'.
The underling dataset will still try to save the changed event. (Line 490 in cxSchedulerEventEditor is triggered and on Line 892 the data will be persisted, as the modified recordset was never canceled)
I will attach my video in a second.
Kind regards
Jonas
Sorry, it will take me half an hour, deleted the prepard video transcript. :-)
The application is started twice ('left' and 'right') with a visible event 'test121'.
Both applications open the event.
The left application changes the event caption to 'test1213'.
The right application changes the event caption to 'test12'.
The right application saves the event with OK. Event gets saved, all ok.
The left application saves the event with OK. Database failure as expected. The error gets confirmed with OK.
The left application clicks to 'Cancel', the 'Do you want to save changes?' Dialog appears.
The left application clicks to 'No' (='Nein' in german). The database delivers the database failure again. (THIS IS WHAT I DO NOT EXPECT, because I clicked to 'Cancel'. I know this happens because of an already modified record.)
The left application clicks to 'Cancel', but as the recordset is in modified state, it always tries to persist the changes, therefore bringing up the database failure. This is repeated 3 times.
Finally the dialog is closed by the forms X button and the dialog get's closed. (This is what I would expect on clicking the 'Cancel' button.)
Thank you VERY much for your detailed problem description. The current behavior looks incorrect, so I have forwarded this ticket to our developers for research. As a temporary workaround, you can use the following code:
procedure TcxSchedulerEventEditorFormHelper.Cancel(var AModalResult: TModalResult); begin if CanClose then begin FModified := False; Close(AModalResult); end else AModalResult := mrNone; end;