Personally, I prefer EOR, but I give my clients their choice. One way of handling the problem of dynamically bound controls changing during INIT is to have an 'initialized' form property. Defaults to .F., gets changed to .T. at the end of INIT() or Activate() or whatever is appropriate for your scenario.

I've used this successfully when I have to initialize combos depending on a variable passed in through INIT(). I make the combo's init dependant on the Initialized variable and then re-call the INITs when all the information is present.

As for how to bind the controls, it's a simple method call that is put into each of the base classes for bound controls. Sets a form edit/add/readonly flag and refreshes the buttons accordingly. We have buttons that can be dropped on the form for Add/Save/Cancel etc. that reflect this.

Barbara

>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.