Showing popup menu on tab change

Hi Simon,

When I look at Visual Studio, if you left mouse down over an unselected tab (which selects it) and then drag the mouse over the content area and finally release the mouse button, it also does initiate a drag.  This is by design since it is a select and drag.

I've looked at the VS behaviour and its similar to your docking windows behaviour, but with a small difference, they seem to use window coordinates, not coordinates relative to the tab.

If the tab position does not change when its selected this makes no difference, however if the tab jumps (as the toolbars have changed position - see video) then the relative coordinates of the mouse jump and the drag is initiated on the next mousemove (even if its just moved 1 pixel).

If window coordinates were used then the behaviour would be the same but the tab would have to be dragged a reasonable number of pixels before you called it a drag and initiated the drag tab stuff.

Hope that makes sense!

Hi Simon,

Can you put together a new simple sample project that shows this happening (include repro steps) and send it to our support address so we can debug with it and make sure anything we change fixes the problem?  Please reference this thread and rename the .zip file extension of what you send so that it doesn't get spam blocked.  Thanks!

Hi

I've put together a basic test harness that shows this problem, if you select a tab, the header height changes, in a regular project this would be due to menus/toolbars re-arranging.

When you select a tab, if you move the mouse even slightly between the mouse down and mouse up then you get the drag action kicking in.

This is most obvious if you click the tab while the mouse pointer is still moving slightly.

Project file zip

Thanks

Simon

Hi Simon,

Thanks for the sample.  We looked at the tab click/drag code and it actually already is using screen coordinates for the mouse.  Further it's using the SystemInformation.DragSize to determine how far in screen coordinates that the mouse has to move before the drag starts.  So in theory, it appears we are already doing everything properly.

We've changed the code to do a quick check before starting the drag that the selection (and subsequent layout changes) didn't move the tab out from under the mouse.  If that happens, it won't start the drag.  That seems to fix the problem in your sample's scenario.

Hi

Thanks for looking into it, I'll keep an eye out for the next point release.

Thanks Simon