Exactly. Actually the approach I take is my apps is to have a toolbar object, a menu, forms and an intermediary object that ties them all together (StateManager).

For example my oToolbar.cmdSaveRec.Click contains:

 oStateManager.Execute("SaveRec")

oStateManager.Execute contains:

LPARAMETERS tcMethod

IF TYPE('_SCREEN.ActiveForm.Name') = 'C'						&& Is there an active form?
	IF PEMSTATUS(_SCREEN.ActiveForm, tcMethod, 5)				&& Does ActiveForm have .(tcMethod)?
		RETURN EVALUATE('_SCREEN.ActiveForm.'+tcMethod+'()')	&& Execute ActiveForm.(tcMethod)
	ENDIF
ENDIF
RETURN .F.

>Hi Colin ---
>
>This is sort of a "me too" post. I've done the same sort of thing since VFP3...it works great because you have a central source for your Save, Revert, et al.
>
>I'd like to add that one should make sure you use PEMSTATUS() to ensure the property exists on the active form. What also helps is to enable/disable toolbar nav buttons using got and lostfocus in the form class.
>
>
>>Basically yes. I use a generic toolbar for all my forms with buttons for first, previous, next, last, new, edit, save, revert, delete, and exit form. The toolbar has no real code except to call custom methods in the active form. i.e. cmdSaveRec.Click has _SCREEN.ActiveForm.SaveRec. If _SCREEN.ActiveForm doesn't have a SaveRec method then cmdSaveRec.Enabled=.F.
>>
>>>Do I assume correctly that you have added the properties, edit, save, and revert to your form. And do you use edit/save/revert command buttons for editing data?--lincoln