Thanks, I haven't checked out your classes lately. I will have to revisit them!

I did see the code you have in the valid, but I guess I'm a bit confused at the circular logic of this .value = .value statement. What do the two values refer to? Not to be dense, but algebraically speaking, saying a=a should not yield a different result...


>Did you try committing the value? Otherwise it has the previous value. IOW whatever the currentcontrol is, call:
>
>

>this.Value = this.Value
>

>on it. You can see this implementation in FoxyClasses EditableGrid class:
>
>https://drive.google.com/open?id=1s5kfyL-LP8X2EJqwI7K-TPLzR69yzbjP
>
>>I have a grid in a formset that has a peculiar problem. The grid is databound to a writable query, which updates the underlying table upon row/column change. I have figured out that if you tab out of the field for a column change, the code below works perfectly. However, changing rows will 95% of the time not update the table with the replace statement. The weird part is, if I trace through the method, it always works. I have to set a code break after the replace statement to see that the replace doesn't work.
>>
>>Example: If I change a field from "25" to "35"
>>if I stop the code immediately below the replace statement, I get:
>>jcwolabor.milebill = "25" (not updated)
>>labtempdet.milebill = "35"
>>
>>if I do the same and move right or left, they both show "35"
>>
>>If I stop the program immediately before the replace statement and step through the code, it works no matter which way I move - very frustrating.
>>
>>Here is the grid.beforerowcolchange code:
>>

>>LPARAMETERS nColIndex
>>
>>= thisformset.calcot()
>>replace hours WITH thisformset.calcreg, othours WITH thisformset.calc_ot, dthours WITH thisformset.calc_dt IN labtempdet
>>
>>IF SEEK(labtempdet.labkey,"jcwolabor","primary")
>>	SELECT jcwolabor
>>	replace jcwolabor.dos WITH labtempdet.dos, jcwolabor.desc WITH labtempdet.desc, jcwolabor.techid WITH labtempdet.techid, ;
>>		jcwolabor.truckid WITH labtempdet.truckid, jcwolabor.timestart WITH labtempdet.timestart, jcwolabor.timeend WITH labtempdet.timeend, ;
>>		jcwolabor.mileage WITH labtempdet.mileage, jcwolabor.milebill WITH labtempdet.milebill, jcwolabor.milerate WITH labtempdet.milerate, ;
>>		jcwolabor.hours WITH labtempdet.hours, jcwolabor.laborrate WITH labtempdet.laborrate, jcwolabor.othours WITH labtempdet.othours, ;
>>		jcwolabor.dthours WITH labtempdet.dthours, jcwolabor.billhours WITH labtempdet.billhours, jcwolabor.billot WITH labtempdet.billot, ;
>>		jcwolabor.billdt WITH labtempdet.billdt, jcwolabor.tripcharge WITH labtempdet.tripcharge, ;
>>		jcwolabor.updated WITH DATETIME(), jcwolabor.updatedby WITH ALLTRIM(STR(o_app.loginid)), ;
>>		jcwolabor.comment WITH labtempdet.comment IN jcwolabor
>>
>>ELSE
>>	WAIT WINDOW NOWAIT "Unable to save to jcwolabor..."
>>ENDIF
>>

>>
>>note: the seek always seems to work - the record pointers appear to be in the correct place when I've stopped before and after the replace statement.
>>I left the calcot method in the example, but all it really does is recalculate fields in the existing field, so there shouldn't be any pointer change on labtempdet.
>>I originally was doing a replace with a for clause, but it had the same result. I have also tried a SQL update statement, with the same result.
>>I have taken any buffering off the jcwolabor table - same result. This is happening on two different form/grids in the formset, so I assume this is expected behavior and I"m missing something obvious...
>>
>>What am I missing? Any thoughts would be greatly appreciated!