>>>>>>At this point, i think you should reverse your smily to :(
>>>>>>
>>>>>>In my tests putting 1 in either displayvalue or value
>>>>>>show the first list element when the form was display...
>>>>>>
>>>>>>May be you have played to far with the setting of this listbox?
>>>>>
>>>>>Then, in that case, you'll be amazed when you'll run the sample form I just sent you. ;)
>>>>
>>>>It works...
>>>>When i remove the 17 in the value property
>>>>and put 1 in the displayvalue property.
>>>>
>>>>Only a @%^\* typo!
>>>
>>>I really don't understand.
>>>
>>>I never put 17 in the value property. When I open it here it shows 0. I can't succeed in making a value to be saved in either Value or DisplayValue property. As soon as I go back in the form, it's 0.
>>
>>Ok, I have found the bug. There is definitely one.
>>
>>The Value and DisplayValue properties not being saved are subject to the BoundTo property set to .F. but overwritten. I mean that if you right click to set to default, it'll appear .F. non bold which is in fact the same think as overwritting it with .F. in bold but VFP seems to not like it.
>
>Michael, I have run into this problem in VFP6 also. I ALWAYS 'set to default' so it appears in non-bold (thus a default value). If you overwrite it with .f. then that is not a default value (you wrote the value and hence it is bold). I think this comes into play more on properties and methods that are changed at runtime--it needs to distinguish between a value of .f. that will remain false (because the user set it at design time) or a value of false that can be changed (because it is set to the default value which may default to .t. in the next version).

Yes, but at the end .F. is suppose to be .F. right? :)

So, at run time, no matter if it comes from the system or from the user, .F. is .F. thus shouldn't have any impact on the running process.