>>>>>>>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.
>
>I don't know Fabio.
>
>I think that all those decisions are taken above their heads anyway.
>
>They cannot control it and neither can anyone of us
>
>
>Que sera, sera
>
>
>UPDATE: this is a known problem http://support.microsoft.com/default.aspx?scid=kb;en-us;165169

February 4, 2000
The bug has been found in VFP6,
it is present from VFP5 and after 5 years and 3 versions it is there still.