Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Row change in grid - replace statement doesn't complete
Message
 
 
To
23/11/2018 13:47:49
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Environment versions
Visual FoxPro:
VFP 9 SP2
OS:
Windows 10
Database:
Visual FoxPro
Application:
Desktop
Miscellaneous
Thread ID:
01663745
Message ID:
01663772
Views:
38
So, I didn't see a lot in the coverage logger of help as it just showed what I expected for events. I didn't have any valids running on the field - I added a replace statement there and that seems to work just fine. I was looking for a more generic way to update the fields at the grid level (i.e. lazy), but I'll go ahead and wire up each field in the valid methods individually.

Thanks again and have a great weekend!



>>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!
>
>The problem is most likely that the moment when the event is firing, the underlying controlsource has not yet been updated with the value typed into the grid column textbox. This is usually completed when the Valid of a control fires. That is the reason it works with debugging, because the recordsource got a chance to udpate.
>
>A workaround could be to work with a timer that fires the code delayed. The challange with that is that you may have moved already to another row, so you have to save the position in the cursor and reset it.
>
>Alternatively you could bind to the LostFocus event of each control.
Steve Howie, owner
DaSH Technology
Denver, CO
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform