Actually, after I minute's thought, you probably up to something. For the state we're using a combobox with some custom code. Perhaps, there is an assignation there...

>We'll try to look very hard for that, but I really doubt. The form doesn't have any custom code and it's modal.
>
>>I strongly suspect that you DO assign the value somewhere in the code. This would require some careful debugging. Perhaps you should put a breakpoint, for a change in GetFldState() or something similar.
>>
>>Note that making a change and then reverting it, or even REPLACEing a field with the value it already has, will mark it is "changed".
>>
>>>Hi everybody,
>>>
>>>My colleague and I spent more than 4 hours today puzzling our heads on a very weird problem. He has a very complicated form with lots of business objects. There is a button on that form, which calls another form. That form is modal and it doesn't contain a biz. object. This form has a Default DS, so it shares DS of a calling form. This form has textbox controls bound to two views from the main form. Now, if we don't invoke that form, the main form behaves correctly. Once we invoke it and immediatelly close, it reports that something was changed.
>>>
>>>The button just calls that form with DoForm('childform') command.
>>>
>>>We found, that after we invoked the form, the GeFldState function returns 343333333433333333. The second 4 is a new primary key, so it's fine, but the 4 on the 10th position is unexplainable. That field is cState_Code and it was not touched any way. Moreover,
>>>I put
>>>scatter name loBefore
>>>doform()
>>>scatter name loAfter
>>>=messagebox(compobj(loBefore, loAfter))
>>>=messagebox(getfldstate(-1))
>>>
>>>And compobj returns .t. while GetFldState reports a change on that field. The field is empty before and after and it is not null.
>>>
>>>We're stumbled.
>>>
>>>Do you have any explanation for that strange behavior?
>>>
>>>Thanks a lot in advance.