But then again, wouldn't it be really easy to implement it, sure you'd have to write the code for every control class, but I've seen more elaborated, and extensive code in some of the responses you guys post here. Maybe not to deal with every type of container but just forms, which is really where it's needed.

>Correct!
>
>>So basically you wsih it was an integrated feature, rather than having to implement it right?.
>>
>>>I sort of wish this worked like the Keypress event, which can be trapped at the container (form) level as well as the control.
>>>
>>>>The MFC approach is basically setting a flag whenever a change occurs, no info about who did it though, couldn't this be done with a property called.. uh lDataChanged on the form, that's set by the interactive change of the controls in a form, maybe have an assign method for it, or a method called DataChanged, that sets the flag, and calls a form refresh.
>>>>
>>>>>Let me do a redux on this issue: It just occured to me that GETFLDSTATE() is not going to help at all. How would I trap a change in a way that saves me from putting code in every parent control classes InteractiveChange? And if I need to use that event, I don't need GETFLDSTATE() because I "know" a change has been made.
>>>>>
>>>>>I go back to my assertion that we need an event in a container (form or container or even page) that fires when a contained control is changed. A GETFLDSTATE or InterActive change for containers. I think the best syntax would be:
>>>>>
>>>>>ContainerInteractiveChange(cObjname,cChangeSource)
>>>>>
>>>>>Parms:
>>>>>
>>>>>cObjName. The (relative to the container) object name that was changed.
>>>>>cChangeSource. What event/method fired the change? InteractiveChange, ProgrammaticChange, ehat?
>>>>>
>>>>>Sorry ... just going stream of conciousness here ;-)
>>>>>
>>>>>
>>>>>>No problem. Hope it works.
>>>>>>
>>>>>>Michelle
>>>>>>
>>>>>>
>>>>>>>It wouldn't always work standalone, that's the problem. You'd still need a means of trapping changes where the data is not directly bound and not immediately kicking off changes in the GETFLDSTATE value. But I'm game to try it and will post the results here. Thanks again!
>>>>>>>
>>>>>>>
>>>>>>>>Let me know if it works if you try it. I've never done an edit on request.
>>>>>>>>
>>>>>>>>Thanks,
>>>>>>>>
>>>>>>>>Michelle
>>>>>>>>
>>>>>>>>
>>>>>>>>>There is (GETFLDSTATE), and that's not a bad idea.
>>>>>>>>>
>>>>>>>>>>I've never tried this, so maybe it wouldn't work. But couldn't you just check if the table has been changed? I thought there was some way of finding out if the table has changed. So you put a check for that in the refresh of your cancel button.
>>>>>>>>>>
>>>>>>>>>>Michelle