>Hi!
>
>See comments below...
>>>The buffering of the second instance wouldn't matter, because its changes would be flushed anyway once it was closed.
>>
>>If I surround refresh and all other methods with thisform.lockscreen=.t., would it stop execution of myForeCOlor, when it's not needed?
>
>I guess no. LockScreen has nothing to VFP events logic, and while grid is refreched, Denamic* expressions will be evaluated anyway, though you just will not see results (because screen is locked).
>When you move the record pointer and certain things happen inside of teh VFP, grid is also refreshed (to change current row) and a bunch of events firing. In particular, this can happen with DOEVENTS and grid having focus. Try to set focus outside of the grid for duration of the process, call DoEvents before saving to make all events for grid finish, set _VFP.AutoYield to .F. and run updating process again.

Not sure, I understand, what should I do. I have some custom code in Form.Add method (Add becomes save in EditMode):

with thisform
   llPrevLock = .LockScreen
* check for exit from edit mode via Save button
	if .EditMode	&& this button means "Save" when in edit mode		
	   .LockScreen = .t. && Don't want to change color in grid
* handle non-blank stateuse validation if applicable
		if not empty(.deduCombNew) and .dedupetype = DDJC_PRCL	&& newly combined parcel
* check that the user supplied a non-blank stateuse
			lnRecno=recno('BldMstr')					&& save current position
			go (.deduCombNew)				&& jump to the new combo parcel
			if empty(StateUse)						&& user didn't select a stateuse for new combined parcel
				wait window nowait "A non-blank StateUse is required for newly combined parcel."
				.grdBldMstr.DDCP_STUSE.combo1.setfocus()	&& put focus right on the offending field
				.LockScreen = m.llPrevLock
				return								&& may as well leave position at the offending record
			endif
			goto m.lnRecno					&& restore position
		endif
		.deduCombNew = 0		&& clear property indicating we're editing a new combined record
		dodefault()				&& pass on to default Save logic
		.dedupeCount('Save')
		.LockScreen = m.llPrevLock
		return
	endif

Dodefault() executes saving logic of Baseform. I found problem in this method, but my colleague has to deal with it. I just spoke with her, she would do it on Wednesday, since it's quite complicated problem.

Anyway, where should I move focus off the grid in this piece of code?


>
>>I don't like the idea of setting buffering to 1 and back to 5, it woyuld not work in our framework...
>>
>
>Setting buffering from 5-th bufferng to some another (1st) is not allowed until you will save all changes or revert them.
>
>>Anyway, thanks. I'll try to investigate more on this problem on Monday.
>
>One thing comed to mind: Are you sure updating process is optimized? I meant, for views usually key field is used and only key field is included in the updating "WHERE" clause, so updating of each record in alias looks like:
>UPDATE MyTable SET field1=value1, ... WHERE KeyField=KeyValue
>I guess when you use table buffering for table, it is definitely slow because default settings for UPDATE command is no key field and all fields are included in the WHERE condition. As a resul, updating is way too slow. In such case I would recoomend you to use the view with properly defined key field and WHERE clause setting.
>

I'm afraid, I can not switch to view and have to work with tables instead...
>HTH.