Using WindowManager.History to Find Fields Changed by User on Form

questions
1

Hi,

I have a window that has fields in two categories. One set is fields that can be updated by the user, and will periodically be updated from another data source. If any of those fields have been changed by the user I want to set a flag on the record so the update process will not update it. The remaining fields I don’t care about, the update process won’t touch them.

So, I was hoping to do something like this (in pseudocode)

Loop through either the controls or the record fields
   if the field is something I care about
        if the current control value <> history value
            mark the record as locked
            break
        end if
   end if
end loop

But as a first step I tried to get a column name, by

ThisWindow.gethistoryname PROCEDURE(short pos)

  CODE
  return(who(self.history.frecord,pos))

and get told Frecord and History are fields not found, and HistoryList is not a QUEUE or CLASS type.

So I figure I need some help…

Thanks.

2

HI !
Why not just set the ReadOnly flag for these fields and that’s it.
Why allow fields to be changed so that you can track these changes and not save them?

3

I guess I didn’t explain myself well…

The first set of fields has the client contact info and the most recent amounts of assistance the client receives.

We are trying to sign them up for a new program, so there is a second set of fields that has progress in contacting people and getting them signed up.

Each month we refresh the first set of data from another source – they may have moved, be getting different assistance, etc.

Sometimes, in the process of trying to get people signed up we will find out that some of the first set of info needs to be changed – they have a new phone number, or get some sort of assistance that wasn’t in the other source of data, but should have been. If we change the data based on what we learned from the client, we don’t want the monthly update to overwrite it. But normally we do want to overwrite it. That’s what the flag is for.

I gave up on trying to use the History property of the WindowManager. I just filled my own buffer on entry to the form, and checked for changes right before writing the record back.

4

The FieldPairsClass is nice for comparing subsets of fields. Once you add the field pairs that you care about, you can check their equality, copy left to right or right to left.

But all of the field assignment is done in one place, and it’s easy to maintain.

2 Likes
5

Another way would be 2 GROUP’s with Before and After. Use LIKE() to assure same Type and as long as the Field Labels are the same you can use Deep Assign.

BeforeVendor  GROUP,PRE(BeforeVen)
Name            LIKE(VEN:Name    )
Address1        LIKE(VEN:Address1)
Address2        LIKE(VEN:Address2)
City            LIKE(VEN:City    )
State           LIKE(VEN:State   )
Zipcode         LIKE(VEN:Zipcode )
!^^^^^^  Must be same as ^^^^^^^ in File so Deep Assign :=: works 
              END

AfterVendor  GROUP(BeforeVendor),PRE(AfterVen)
             END

   CODE 

!----- Save Before values before ACCEPT  -----
   BeforeVendor   :=: VEN:Record 

...

!----- Check for changes -----
   AfterVendor :=: VEN:Record 
   IF AfterVendor <> BeforeVendor THEN 
      Message('It changed from Before')
      !Could Loop using WHO() WHAT() or use BeforeVen:xxxx and AfterVen:xxxx fields
   END
6

Cool. I wasn’t even aware that class exists. Thanks.

7

That’s what my BitPairsClass is based on, but it’s for bits instead of whole fields.

8

If I wanted to be really cool, I guess I would combine Carl and Jeffs ideas:

Use the two groups method to set up the place to put the fields I cared about, and deep assign to populate it on entry, then an &= loop to add all the fields in the savedbuffer group and the file buffer to the fieldpairs class. And at the end I’d just do an EqualLeftRight to see if I need to marked the record as locked.