Placing caret inside a selection does not reset selection

Hi Joris,

I just tried it on Vista and didn't have a problem. Note that if you are moving the mouse when you click, you may be initiating a drag operation and if you release the mouse button while still over the selection, nothing will change, thereby emulating what you are describing. However clicking without moving the mouse past a threshold should work fine.

I've just tried it again, and unfortunately still get the same unwanted behavior.
I tried on Vista Ultimate x86 with dual core, Vista Ultimate x64 with dual core.

I had the same trouble as you with reproducing (this is actually a bug of one of our customers). Initially I wasn't able to reproduce it; then I was, next I wasn't and now I am again. It is really confusing.

To provide some more detail; I run the sample application, double-click on ComponentModel and next (single) click in front of Model to get the cursor there. I do indeed see the cursor icon change as if it were a kind of dragging operation that I'm initiating. I'm quite sure that as software developer for the past 10 years that I'm not as mouse-challenged as some end-users are, and besides that it works fine on XP/2K.

When I copy the text to e.g. Word and try to do the exact same operation (on Vista), it works fine in Word and I do get the selection canceled and the caret in front of Model.

Maybe it has something to do with timings between the Mouse Up and Down events or ...

I hope you'll be able to reproduce it ...

PS:
We use your specially build version of the 3.1.0222 release as a fix for 'Issue causing a crash / red cross in the Syntax Editor'

[Modified at 08/13/2007 08:27 AM]

Hi Joris,

After looking at the code, v3.1 didn't have a drag threshold set up (meaning you must move beyond 3 or so pixels before a drag starts). Therefore any slight movement would start a drag. v4.0 did have the proper code in place. We moved similar code into v3.1 and will put out a maintenance release soon with the update.

Ok, that's great, although it might not be necessary / the appropriate solution; we've just found out that the problem does NOT occur when we 'Run as Administrator' the sample executable. Any chance you disabled UAC on your computers? I suspect Microsoft.NET or you are apparently issuing some call that is privileged to the administrator user in that part of code ...

So I guess the steps to reproduce start with enabling UAC and logging as user who does not have administrative rights ...

[Modified at 08/13/2007 09:05 AM]

Correct that appeared to reproduce it. I could repro it with the old code and then with the changed code it no longer appeared to occur. My belief is that Vista sends an extra mouse move message through so without the threshold check (which is added now), it would initiate the drag.