I was just dealing with this today.  It seems Larry's summary is correct.  Plus, it appears that RBTI__DIRTY_FLAG does change to 1 when tabbing out of a field and staying on the same row.  It stays zero until you leave the field.

To trap the RBTI_DIRTY_FLAG for processing after leaving a DB Grid, I tried On Row Exit and After Leaving Section table EEPs with

SET VAR vRowDirtyFlag = (IFEQ(RBTI_DIRTY_FLAG,1,1,.vRowDirtyFlag))

Unfrtunately, neither EEP fires if I change data and then click a Push Button elsewhere on the form.
But putting the code in an After Saving Row EEP seems to trap the 1, although I would have thought that by then it's too late - the row has already been saved and RBTI_DIRTY_FLAG is reset to zero.

Enlightenment?
Doug

Emmitt Dove wrote:

I see that my error was viewing the dbgrid as one db object.  It is really a collection of many.

 

But, I accomplished my goal by emulating the sys_rowver technique (without setting autorowver on.)

 

Emmitt Dove

Manager, Converting Applications Development

Evergreen Packaging, Inc.

[email protected]

(203) 214-5683 m

(203) 643-8022 o

(203) 643-8086 f

[email protected]

 

From: [email protected] [mailto:[email protected]] On Behalf Of Lawrence Lustig
Sent: Wednesday, March 25, 2009 11:02 AM
To: RBASE-L Mailing List
Subject: [RBASE-L] - Re: RBTI_DIRTY_FLAG

 

<< 

Should I be expecting .RBTI_DIRTY_FLAG to return 1 if a value was changed in a dbgrid?

>> 

 

Depends whether you scrolled out of the row or not.

 

If you have already scrolled out of the row, that row has been saved, and the RBTI_DIRTY_FLAG should reset to 0.

 

If you have NOT scrolled out of the row, but have tabbed out of the field you changed, I would expect RBTI_DIRTY_FLAG to contain 1, but I haven't tested it.

 

If you have neither scrolled out of the row NOR tabbed out of the field, then I would imagine the flag would still be 0, since the change in the field has probably not yet been written back into the form's row buffer.

--

Larry

 


Reply via email to