Hello Jim

it seems that if you manually set the 'MousePointer' property to "3 - I-Beam" you will always get that behaviour.

it wanted to see if any of the properties would remedy that problem, but no luck.

UPDATE:

well, well, well

it seems that the property "Mouse Pointer" is for the button only! Try setting it to '1 - Arrow' and i think you got it fixed. i could not get that undesired behaviour repeated.

>Thanks for checking Sergey.
>
>Hopefully JimS will pick this up and report on my behalf. I will add to the UT bug list.
>
>Amazing what users see that I/we just don't see for lack of looking!
>
>cheers
>
>>I see this with a plain combo droped on a form. Looks like a bug to me.
>>
>>>Hi all,
>>>
>>>A subclassed Combobox will exhibit the following characteristics on a form (the control(s) in question are 3rd-level of containership hierarchy), vis-a-vis the mouse pointer, when mousing across the data (input) area towards the dropdown arrow...
>>>
>>>1) as expected, the pointer becomes the I-beam as it enters the input/display area from the right, top, or bottom.
>>>
>>>2) the I-beam persists, as expected, mousing across the same area, towards the drop-arrow.
>>>
>>>3) On reaching the drop-arrow it REMAINS AS I-BEAM.
>>>
>>>4) Continuing across the drop-arrow the I-BEAM PERSISTS.
>>>
>>>5) Reaching the right edge of the drop-arrow the pointer reverts the the (proper) pointer.
>>>
>>>It was expected that the I-beam would change to the standard pointer immediately reaching the drop-arrow.
>>>
>>>Now clicking on the drop-arrow and clicking on an entry to have it display in the text area and repeating the above, the I-BEAM-to-POINTER transition happens correctly (as it reaches the left side of the drop-arrow).
>>>
>>>This occurs not on every combo, but on approximately 90% of them.
>>>
>>>Anyone seen this and know of a fix/bypass?
>>>
>>>Thanks
>>>Jim