Hi John,

You know, I've been wondering how to implement that. I did add a lModified to my base form and played around with changing it to .T. through the InteractiveChange an ProgrmatticChange methods. I of course run into problems with dynamically bound controls. If they change during the init phase of a form, lModified gets set to true.

I've been thinking an ObserverPattern class might solve the problem but I'm still tinkering with it.

BTW I'm part of the EOD faction myself. Question: How many apps have you seen (not including fox developer generated) that follow the EOR pattern? Just wondering.

>Hi Sylvain!
>
>Before I'll universally buy into not having a Modify button on a form, I'd like to see a new container property that would be set .T. or .F. is there were any changes to controls in the form. Right now, to completely implement this sort of UI, you have to build all sorts of code into each bound control to see if the user is actually editing anything so that your controls are set right. For example, I don't want an Undo button enabled until there is actually something to undo. That behavior is a PITA to code as you have to make it functional in ALL form controls to work consistently.
>
>
>>I don't use edit buttons in my forms since TableRevert() came along. Since it's easy to revert a change, I won't force user to do an extra step to change a field.

---

>I recently started using VPM, and was surprised that they don't implement an edit mode by default, they recently added some functionality to do so, but it's not fully supported, in their documentation they say that having forms always in edit mode was a more common practice since VFP came along.
>>>
>>>I've always used an edit mode, and prefered it, because it's harder to mess things up this way, so I was surprised to hear that this was an "uncommon" practice ... what do you all think?, do you use an edit mode?