>>>>>>Expected: stable into Page1.
>>>>>>
>>>>>
>>>>>Fabio,
>>>>>
>>>>>Where is documented that NODEFAULT in DEACTIVATE should have any effect?
>>>>
>>>>It works. E.g. page stays active. Of course, page has to have some objects on it.
>>>
>>>Changing page with the Right/Left keys,
>>>you don't succeed in stopping the operation into Deactivate,
>>>only with KeyPreview and NODEFAULT on the Form.Keypress
>>>it is possible to stop the change page.
>>_________________________________________________________
>>Fabio,
>>
>>I discovered this a long time ago, don't remember when
>>
>>I have a standard maintenance form class ( a la Tastrade ). A form with a pageframe consisting of two pages
>>The left page allows you to modify a record, the right page gives a list (grid) of all records
>>
>>In the left page's DeActivate event, when the data has changed, you get a prompt: Save ? Yes No Cancel
>>
>>The cancel does a NODEFAULT.
>>
>>Now, when one is on page1 caption and a LeftArrow or RightArrow is pressed it produces a page DeActivate event.
>>When a NODEFAULT is done there, it is not reliable, ie it switches to page2 anyway
>>
>>Since then, I have the following code in the form Keypress (the solution you are suggesting)
>>
>>

>>do case
>>case inlist(nKeyCode, nKEY_LEFT_ARROW, nKEY_RIGHT_ARROW)
>>	local ac
>>	ac = this.GetActiveControl()
>>	if( !isNull(ac) )
>>		if( ac.BaseClass = 'Page' )
>>			NODEFAULT
>>		endif
>>	endif
>>...
>>

>>
>>When you are on page1 and you click on the header of page2, the NODEFAULT works without any problem. It's just the arrow keys that may cause a problem
>
>This is a possible way, but:
>- it require KeyPreview =.T., but with Keypreview =.T. I have found more than a bug.
>- with keypress's NODEFAULT the page changing with the keyboard it is removed,
>if the decision is taken on the deactivate event , it needs to be appraise it on the form.keypress
>- difficult to manage a pageframe inside a grid? (it is not essential)
>
>All feasible, but it complicates notably the life.
>
>Instead of wasting time with SEDNA, a project to connect two environments
>rather tottering, why first they are not systematized the about fifty of
>problems on the visual interface of VFP.

Well I sure hope and expect that FIXING BUGS remains a top priority of the VFP Team (what's left of it).
Many many people have also mentioned addressing the Grid's functionality too, which would include both bugs and commonly required functionality that is currently lacking.

cheers