Thanks for looking at this. I'm trying to see what I'm missing about this. This is my simple test, and yes there was a sneeky refresh in my navigation button class:) On new form I place textbox with command button with click event code:
select tableA
skip
thisform.textboxA.refresh
Then I place a textboxA with a value_assign method in its class with no code.
In the value_assign method in the object I put:
this.value=vnewval
wait window "va firing"

This textbox is bound to a logical field of tableA. Upon clicking the command button after running form I get vafiring on every click.

Is this the result you got the opposite of?

Thanks again.


>I've done the simplest test I can think of for this, and found opposite results. What's more, changing record pointer doesn't do anything at all- you have to call the textbox's refresh for the value to change.
>
>>Yes, firing occurs of the value_assign event of the textbox or checkbox that is bound to a table each time a record change occurs in that table. I've only checked these two controls which are simple subclasses of their baseclasses.
>>
>>>>In the case of checkbox, Interactivechange is one thing, Programmaticchange is another, and change due to record change of a table that checkbox is bound to is another it seems. So Value_Assign became extra important to me here as I needed a large label to show an X when bound field was true. This is just an indicator and the user cannot change the value.
>>>
>>>That Works!?! The point of the thread was it there is no way to tell (on the control, using Data objects is the other story) that the value changed IF it was a change in the controlsource (Programmatic, InterActive, and Value_Assign all don't work). Or are you talking about a middle man object? Thats where I got messed up before :-(