You can view the dbgrid as a single object - and certainly in the forms builder it is, but what I was getting at is that it is made up of rows and columns. Each of those cells is a field on a table. One dbedit = one field in the current row of a table. Think of the dbgrid as a variable number of dbedits.
By the way, it just occurred to me that if you really need better control over what happens moving into or out of individual fields, you *could* build a scrolling region to look and act very much like a dbgrid. The advantage would be all the on-entry, on-exit and on-click eeps available. What you lose is the ability to move columns around and sort by clicking the title. But even the sorting could be emulated, if the region is based upon a view. 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 Doug Hamilton Sent: Friday, March 27, 2009 6:39 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: RBTI_DIRTY_FLAG Possible. But I think my "best practices" aren't the best. I'm editing permanent-table data (inventory xacts) in a db grid. I think it's better to load the xacts for the particular item into a temp table & use the SYS_ROWVER approach to determine which rows were changed and then update those rows in the permanent table. Each row has a unique ID. You're right - We don't need no steenkin' dirty flag! (just a RowVer column) BTW, GOTH.com, what did you mean by: I see that my error was viewing the dbgrid as one db object. It is really a collection of many. DBGrid has but one Component ID ( I think), although one can determine which cell one is in by GETPROPERTY CIDDBGrid CURRENTCOLUMNNAME 'vCurrColumn' and form expression vRowID = RowID. Is that what you meant by many db objects? ohmmmmmmmmmm.... Doug Emmitt Dove wrote: Doug, Another thought: how about using a trigger on your table to set a global variable for you? 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 Emmitt Dove Sent: Friday, March 27, 2009 6:08 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: RBTI_DIRTY_FLAG >Enlightenment? >Doug Available at GuruOnTheHill.com. |-) The problem is how to capture the value at the proper time. There's no on-entry-into-field eep or on-exit-from-field eep in the grid. As you note, by the time you leave the row the row is saved and the dirty flag should be 0. For my purposes, I needed to know if any of the rows in the temp table represented by the dbgrid had been changed. I accomplished this by adding a column to the temp table named "myrowver" type integer, computed to be (IFNULL(myrowver,1,(myrowver + 1))). First I populate the temp table (which involves an INSERT and a few UPDATEs) then ALTER TABLE to add the myrowver column. As I go into the form each myrowver value is 1. When it is time to figure out if an update to the permanent table is in order, I look to see if any rows have myrover > 1. We don't need no steenkin' dirty flag! 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 Doug Hamilton Sent: Friday, March 27, 2009 5:39 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: RBTI_DIRTY_FLAG 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
