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