Martin schrieb:
Try the following,
- open one or 2 sources in the main window (just to make sure you have
some tabs)
- show object inspector (or messages...) and dock to the main window
( it must be docked to the main win, or it will not happen)
- now grab the OI at it's top left corner and start dragging
You should see the dragging rectangle for the OI. The mouse should touch
(or be within pixel distance of) the corner of the rectangle
Move the mouse over the remaining tabs (and keep moving / move from one
tab to the other and back, possible with a simultaneous up/down move).
Because the mouse and the drag border are over the tabs at the same
time, the border leaves ghost images of itslef (windows)
The reason is that the tabs redraw themself if the mouse goes over (in
order to show a bit of highlight indication) [ so the whole thing is
theme dependent ]
Since the mouse is captured while dragging, no other control should
react on mouse moves itself. If this will happen, it's a flaw in the
widgetset or dragging model itself[1]. At least I could not get such
unwanted visible component feedback on Linux/gtk2.
I admit that the tabs react on Win32, and that consequentially artefacts
may be possible, even if I could not produce any.
Artefacts may come from other events, e.g. when a OnDockOver event
handler updates the statusbar, and the dragging frame moves over the
statusbar, but that then is a bug in the application.
Since the frame draws deletes by inverting the screen, any changes to
the screen (as the redraw of the tab) causes frame-fragment to be left
behind.
AFAIK Paul implemented the dragging frame on gtk2 by a transparent (top
level) window, that should be clipped or repainted properly in any case.
The same may be implemented for other widgetsets as well.
------------------------
I haven't looked at your code.
No need to do so. The sample application shall demonstrate *both* the
possible and impossible features, feasable with the existing docking
model. All bug reports and suggestions are welcome, and I'll either try
to reflect them in the demo program, or leave them for the docking
redesign discussion.
but the IDE does "setCapture" (same as MouseCapture := true) to the
control that is going to be dragged. That way all mouse events go there,
and the tabs don't get them.
That's part of the DragManager LCL logic, that cannot be changed by any
application. What you see is an effect from one of the many flaws in the
Delphi drag-dock model, and should be remembered for the discussion of a
general docking redesign.
[1] One of my older suggestions addresses exactly the improper handling
of the mouse capture, where all mouse events should be filtered
immediately (TApplication.ProcessMesssages?), when a mouse capture is
active. This will eliminate according tests within the further message
handling, and will eliminate any chance that other components will fail
to handle a mouse capture properly. Such a filter would not (adversely)
affect the performance of the message handling system, when it checks
for an active mouse capture first, before any filter logic (tests...) is
applied.
DoDi
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
