Using Delphi Berlin.
I have a nested Clientdataset in a datamodule ("dmCore").
There are about 5000 records in the detail table for any given master item (testing with 2 master records).
I have a "Post" button connected to an action in ActionManager.
Its OnUpdate is simple:
actPost.Enabled:=dmCore.HasChanges;// checks master for changes "HasChanges" is simple:
function TdmCore.HasChanges: boolean; begin result := False; if cdsPSet.Active then result:=(cdsPSet.ChangeCount>0); end; Unfortunately, having CDS.ChangeCount run in the action's onUpdate is taking up huge CPU time (>50%).
I haven't noticed this happen on non-nested CDS...
Is there a simpler (faster) mechanism I can use to see if the CDS has changed? I don't need the count, just the fact that there's a change somewhere.
TIA EdB
13 Answers
Try the UpdatesPending property. I can't say it will be faster, but it's the way to detect if there were any changes in the dataset. So in your case you could actually write just:
function TdmCore.HasChanges: boolean; begin Result := cdsPSet.UpdatesPending; end; The action's OnUpdate event is not the best place to toggle its enabled/disabled status. It is fired all the time.
You might want to move it to the TDataSource.OnDataChanged event. There you can insert the same code as in TAction.OnUpdate and it is triggered only when your data really changed. You can also use the TField parameter to separate between different fields.
Example (sorry I only got C++ Builder, but in Delphi it looks the same):
void __fastcall TForm1::DataSource1DataChange(TObject *Sender, TField *Field) { Action1->Enabled = ClientDataSet1->ChangeCount > 0; } Implement your own invalidation mechanism. This is as simple as a single Boolean variable which, when it's True, it means something has changed, and when it's False, it means nothing has changed. You would then be responsible for updating this for every change and action you make on this dataset.
If it were me, I'd create an inherited class, override everything, and implement an invalidation mechanism. It would be much lighter than the existing methods. Of course it wouldn't be as easy to use in design-time, but it would get the job done in run-time.
