Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Grid Scrolled
Message
From
03/03/1999 11:47:38
 
 
To
03/03/1999 05:35:10
Cetin Basoz
Engineerica Inc.
Izmir, Turkey
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Title:
Miscellaneous
Thread ID:
00187918
Message ID:
00193642
Views:
16
>>>>
>>>>Thank you for your reply, Senna. The current record number (recno()) does not change when I use up/down arrow on the scroll bar. However, it changes when I move thumb up and down, though active row number does not change. I also feel confused by FoxPro Grid's activity when I scroll down to last record in the grid on a Master/Detail form.
>>>>
>>>>My problem is that I have code to verify the data in AfterRowColChanged. The unexpected current record changes triggers unexpected execution.
>>>>
>>>>Wei Lin
>>
>>>Hi,
>>>You're right that recno() changes when thumb is used to scroll. But fortunately it doesn't change in fact and AfterRowColChange is not fired (nor BeforeRowColChange). OTOH activerow changes too (VFP5 not VFP3) and becomes 0 when activerow is not in visible portion. You shouldn't do your verification based on recno() value in scrolled event nor in AfterRCC. When ARCC is used a series of validation would already be fired and you'd step back to previous record to correct it. If for example ARCC fired with AllowAddNew and down arrow in last rec, you would catch invalid data after a new one is appended and that would count two recs to correct. OTOH ARCC would also beat table level validation + row buffering where FP error mechanism would immediately fire.
>>>The best place I have found to verify data is BeforeRCC + valid of grid. This prevents table level rules be verified and FP's own error reporting mechanism is not fired before you (buffering is on). Primary key violation is slightly harder to handle this way but IMHO primary keys should never be imposed to interaction with the user and should be generated. Like Cust_id in VFP's own sample data customer, user generated keys should be something different than primary key if they are ever needed.
>>>Cetin
>>
>>Hi, Cetin. Thank you for your reply. I eventually moved my validation code to BeforeRCC. I feel that is probably the only place for validation, at least in VFP 5.0.
>>
>>One remaining problem is that BeforeRCC fired after Valid event. When I use BeforeRCC to write buffer and use Valid to update table and summarize data (using SQL etc.), the trouble occures. The summarized data is not updated. I do not want to update table in BeforeRCC. Does anybody have a better way to work around it?
>>
>>Wei Lin
>Wei,
>What I do is to keep same (nearly) datachecking routine in both valid and BRCC. Also in BRCC and Valid I issue a .value = .value for currentcontrol (if not done .value in BRCC and ARCC are different if edited). Then if grid has lTableUpdtae = .t. I issue tableupdate in valid. Since BRCC and valid codes are quite similar it isn't a problem valid firing before BRCC.
>Cetin

It probably is the best we can do in VFP.

While I was debuging this part of my code, I noticed another problem - refresh() method. In a OneToMany form, I click on a cell in the grid and change the value, then IMMEDIATELY leave the grid. I write the buffer and then issue TableRevert(.T.) to restore the value in BRCC. After that I call refresh() before exit BRCC. The displayed cell value on the screen is not refreshed (back to the original value). That only happens when I Immediately Leave the grid After make one change. Is there a problem with VFP's refresh() method or I miss something?
Previous
Reply
Map
View

Click here to load this message in the networking platform