Bug in wxAUI's selection of docking position

[abligh]

There seems to be a bug in selecting the docking position of a bar present on both Linux/GTK and MSW. The bar docks where the hint suggests, but the hint is daft!

To illustrate, launch the wxAUI sample application. Locate the rightmost toolbar on the top row (has some folder icons on). Drag it by its gripper vertically down (and a couple of pixels to the right) so it rests as a floating toolbar well inside the main window. Release the mouse button.

Now pick up the floating pane by its title bar, and slowly move it upwards. The first hint appear at the right of the second (lower) row of toolbars (correct). Move it a bit further, and the next hint appears at the right of the first (upper) row of toolbars (correct - this is wher it came from). However, continue moving it up so that the tools in the toolbar themselves are aligned with the first (upper) row. Suddenly the correct hint disappears (whilst the toolbar itself is still marginally below the level of the tools you are docking) and a hint appears below the second (lower) row of toolbars, as if you are trying to add a new row. This is bizarre - if the toolbar icons are lined up pretty precisely with where they were when the bar was docked, the bar should redock there. Currently you have to drop it tens of pixels below.

Alex

[abligh]

There seems to be a bug in selecting the docking position of a bar present on both Linux/GTK and MSW. The bar docks where the hint suggests, but the hint is daft!

To illustrate, launch the wxAUI sample application. Locate the rightmost toolbar on the top row (has some folder icons on). Drag it by its gripper vertically down (and a couple of pixels to the right) so it rests as a floating toolbar well inside the main window. Release the mouse button.

Now pick up the floating pane by its title bar, and slowly move it upwards. The first hint appear at the right of the second (lower) row of toolbars (correct). Move it a bit further, and the next hint appears at the right of the first (upper) row of toolbars (correct - this is wher it came from). However, continue moving it up so that the tools in the toolbar themselves are aligned with the first (upper) row. Suddenly the correct hint disappears (whilst the toolbar itself is still marginally below the level of the tools you are docking) and a hint appears below the second (lower) row of toolbars, as if you are trying to add a new row. This is bizarre - if the toolbar icons are lined up pretty precisely with where they were when the bar was docked, the bar should redock there. Currently you have to drop it tens of pixels below.

Alex

I think I've found the cause of this. When DoDrop is called, it is called (essentially) with a mouse position. That's not quite right, as the window concerned's relationship to the mouse pointer can vary. Consider not only the different effects of picking up the top of the gripper and the bottom of the gripper, but the far greater different effect of picking up the top of the titlebar of a floating pane, and the bottom of the gripper.

How about we convert DoDrop over such that it works out the arrangement of floating panes assuming the top left hand corner of the pane concerned is at the point (pt) passed. So all callers would have to adjust the coordinate passed by the difference between the actual mouse position passed, and the top left hand corner of the window. There seems to be some effort to do this anyway (presumably to cope with the situation when the middle (x direction) of the titlebar is picked up) but it does not appear to be consistent (though I may have misread the code.

Alex