0

Currently I am struggling with monitoring a record field change.

Say, we have a record defined as usual:

TMyRecord = record
  Field1: Word;
  Field2: Single;
  Field3: Integer;
end;

I would like to monitor Field2 and display a dialog box as soon as this field changes from <> 0 to = 0.

It would be better to have a native Delphi debugger way to break on this event, but data breakpoints are not possible here, because there are several arrays of this record, which are distributed over the entire program, and I need to monitor each of them (it means, I should know an address for every data breakpoint).

The next idea is to make a property complementing this field and monitor its setter. This is also not possible, because the record gets loaded from file as a whole (as a binary block) or modified by DLL calls as a whole. There are too many places in this, unknown to me program, that change these records.

My last idea was to put a timer into the record, but

  1. how to create the timer on record creation?
  2. how to solve max timers problem? There are several thousands of these records in the arrays.

I am stuck. Could you propose some other ideas, other than find all the read/write places for this record?

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
Paul
  • 25,812
  • 38
  • 124
  • 247
  • 5
    I think the only viable solution is going to be to encapsulate all access of the field in a setter function – David Heffernan Jul 07 '20 at 11:30
  • Fwiw, in your position, I would temporarily rename Field2 to FField2 and add the setter @DavidHeffernan has mentioned. What would be the problem with that? – MartynA Jul 07 '20 at 17:14
  • A single timer, per array, that would only copy Field2 of each element into a distinct packed array at regular intervals. Then you would be able to set a data breakpoint for the Field2 arrays. Didn't really think over it very much, no responsibility assumed if it gets stuck at some point. – Sertac Akyuz Jul 08 '20 at 20:28
  • Breakpoint is unnecessary though, since there won't be any useful stack trace. Timer code can list the elements those zeroed out just as well. – Sertac Akyuz Jul 08 '20 at 21:14
  • MartynA: The problem is that: 1. Loading the record with something like BlockRead doesn't trigger a setter. 2. In order to make use of the setter I need to refactor each piece of loading code, and there are plenty of them, because the product is "historically grown". 3. Because each change should be agreed upon, I am not allowed to refactor too much. I do not want to refactor in order just to revert my changes later. – Paul Jul 11 '20 at 15:36

0 Answers0