Glenn,

I'd personally call it a BUG. Is this VFP8/SP1?

I feel you'd do us all a favour to add it to the UT Bug list.

You should also wait a bit to see if someone from the MS VFP Team picks it up and reports it for you. If they don't you might want to try to treport it to MS yourself.

>I asked a couple of friends who told me they knew of this behavior in comboxes…but why?
>
>If you make a form with just a combobox and a command button and in the init of the form you…
>
>****************************************************************************
>(FORM:INIT)
>
>SELECT cfieldone, ifieldtwo from sometable into cursor crsJUNK &preferable to have 15-20 records
>
>WITH Thisform.cbo1
> .rowsourcetype = 2
> .rowsource = “crsJUNK”
> .requery()
>ENDWITH
>****************************************************************************
>(FORM:CMD1:CLICK())
>
>WAIT WINDOW Thisform.cbo1.DisplayValue TIMEOUT 1
>WAIT WINDOW Thisform.cbo1.Value TIMEOUT 1
>WAIT WINDOW crsJunk.cfieldone TIMEOUT 1
>
>Thisform.Release
>****************************************************************************
>If you click on the combobox to get the drop down list to display, you can use your mouse wheel to change the current value displayed in the combobox and the it will match to the selected record in the cursor. However if you accidentally (a user) , while the drop down is still displayed, were to RIGHTCLICK on an item in the drop down that is not currently selected you will have successfully moved the record pointer in the cursor but the displayvalue and value of the combobox are unchanged.
>
>Clicking on the command button, and the values for displayvalue and value are equal but are not the same as the value for the field in the currently selected record. If this is default behavior then can someone tell me why? There is an easy solution if the bound column is one but if the bound column is not one then the solution gets fairly ugly….I ask this because a client who had intermittent problems in the past, now with the introduction of more and more mice with a mouse wheel, is getting this issue more frequently. They have coded their application under the assumption that the undelying cursor is on the correct record (I know it’s a bad idea) and they build some cbo classes which are based on lookup tables and of course they are bound a column other than one!