>>>>Programmatic change watches the value in a control. It is fired when the
>>>value is changed from code, and interactive change is fired when the user
>>>changes the value. It cannot be used to watch the values of other
>>>properties
>>>
>>>Alright, thanks for the info. If that is true though and if I'm
>>>reading the question correctly and he is programatically changing
>>>the Enabled or Visible status, all he would have to do in
>>>addition to changing these properties would be to change a value
>>>in a control. This would in turn trigger the programatic change.
>>>I know . . . a lot of extra work when this can be handled much
>>>better with a timed event. Just curious if this could work.
>>
>>Why not make an invisible control with its
>>controlsource=othercontrol.enabled, then watch its ProgrammaticChange
>>event? It just might work.
>>
>>I've tried it, and it almost does ;(.
>>
>>I've made a form with two command buttons and a checkbox;
>>command2.click just flips the command1.enabled, and the
>>check1.controlsource="thisform.command1.enabled". The
>>check1.programmaticchange never fired. Tried interactive,
>>it doesn't fire either. I wanted it to fire whenever I clicked
>>command2, but I also wanted its caption to be changed from
>>"Enabled" to "Disabled", so I put
>>
>> this.caption=Iif(this.value, "Enabled","Disabled")
>>
>>into check1.refresh and called thisform.refresh at the end of
>>command2.click - didn't work either. What's worse,
>>check1.refresh fires before the check1.value changes,
>>(though the command1.enabled has already changed, and
>>the button was greyed or blacked already) so I got the
>>wrong caption all the time.
>>
>>I still believe that using timers to catch events which we
>>can't catch otherwise is just a workaround and includes
>>some risks (overhead, firing when some other, more
>>important event is active), so they need lot of care in
>>order to work fine.
>>
>>Probably the best approach in this case is to add specialized
>>methods to the form which would swap the state of the desired
>>objects, and perform any other action necessary. So, instead of
>>Thisform.command1.enabled=.f., we'd better call
>>Thisform.command1driver("enable") to do that and all the other
>>stuff, and use only that to enable/disable command1.
>
>
>Maybe I wasn't reading your post correctly, but I did not see
>any place that you actually change the "this.value". As Erik said
>you have to change the "this.value" not the "this.controlsource" to
>trigger the programmatic change event. Anyways the point is moot.
>I think Erik's method using timers is going to be a better way of
>handling the problem, for reasons he suggested earlier in the
>thread. Try that first.

To elaborate on Dan's point;
control.programmatic change does not fire when the value of a control source is changed. For programmatic change to fire, youmust explicitly change the value in code: control1.value = "so-and-so". You can verify this by putting code in the programmatic change of a databound control and moving the record pointer. No fire. This really isn't so bad though, I think that if you want code to fire when the value of a databound control changed, you could fire it whereveryou move the pointer from, check the value in the control's refresh (where the value databound control's value really gets changed anyway.)

Your second strategy (though pretty creative) is flawed as well. I believe that the caption property is evaluated only at the control's init, or when the value is explicitly changed. It cannot be used like a gridcolumn's dynamic properties, or like a control source. Also, if the code you posted is what you actually used, I would guess that you got a data type mismatch, becuase a control.enabled property is a logical field, and doesn't evaluate to "Enabled" or "Disabled".

I think that these methods fail because of a simple hard fact: there is no built in automatic mechanism that watches the values of properties of controls and notifies us. Each property takes care of itself internally, and the people who designed those controls didn't think that we developers need to automatically know when the value changes. If we want to know, we have to check it ourselves. The timer method is not only (I believe) the best method we have, but it is the published and standard method not only in VFP, but in VB, and I suspect in other event-driven languages.