Hi Bob,

you could achieve the same behaviour my putting this code intot he InteractiveChange, ProgrammaticChange and Refresh event. Unlike Assign methods, here you are not forced to change the value of the Value property.

Christof

>I was working on a new class this weekend and discovered some interesting behaviour with the _assign method. I was creating a new check box class and what I wanted was to change the color of the label depending on the state of the control. So, in the value_assign method, I put in code to check the passed value and set the forecolor appropriately. This worked very well and I was quite happy.
>
>Then I added the control to a form and while it worked with data my framework starting asking if I wanted to 'save changes' even when all I did was scroll through the records.
>
>Here is what I discovered. With the control bound to a data field, the last line of the _assign method -> this.value = vNewval causes the field state (as identified by getfldstate()) to be set to 2 or modified. The value_assign method is processed each time you do a skip because the control receives a new value. This causes the field state to be set to 2 each time a new value is assigned to the control.
>
>In order to preserve the behaviour I wanted, I added a call to GETFLDSTATE before this.value = vNewVal and after the call I did a SETFLDSTATE back to this value. This produced the behaviour I wanted. It is interesting to note that the datasource (the field) received the new value and was updated before the value_assign method was called. GETFLDSTATE returned the correct current value during execution of the value_assign method. Thus, if I scrolled through records, the field state was 1 in the value_assign method, but if I checked or unchecked the checkbox the field state was now 2 when the method executed.
>
>The conclusion here is that you must be careful when using value_assign with bound controls.