Apache OpenOffice (AOO) Bugzilla – Issue 123765
Drag-drop of color does not work for undocked Color Bar
Last modified: 2017-05-20 10:33:53 UTC
Launch Draw or Impress. Activate the Color Bar. You find it in View > Toolbars. The Color Bar is likely docked, if not dock it. Draw a rectangle or another shape and leave edit mode. Drag a color to the shape. When the mouse is over the shape the cursor should change to a plus. When you now release the mouse button the area of the shape should get a new color. Apply a gradient to the shape and call the "Interactive Gradient" tool. Drag a color from the Color Bar to a gradient handle and drop it there. This gradient color will change. Now undock the Color Bar and do the same. Notice, that drag-drop of colors do not work.
What is interactive gradient tool? Can not undock in Impress.
To undock: Go with the mouse from slide down to the color bar. Coming to the edge you will notice, that the cursor changes to the double-arrow. That is the sensible area for resizing the color bar. Go a little bit further down, but not on the colors. When you now click and drag, the color bar should become free. Or activate color bar for example by clicking on "none" (top left item) and then Ctrl+Shift+F10. Use View > Toolbars > Mode or insert the sub-toolbar "Effects" to the drawing toolbar. In this toolbars you find the tool with the simple tooltip "Gradient". Its associated command is ".uno:InteractiveGradient". The icon is enabled, when a drawing object is selected, that has got a gradient filling.
ALG: Both findings are correct, grepping task (having no idea what is different in non-docked, but we will see). BTW: It's working in AOO3.4.
ALG: This is very strange - I have prepared a debug version of trunk for today to check this - and all is working well now in that version. Need to check if this also works in a buildbot version, or if it has to do with debug code...
ALG: Installed the snapshot 1537977 and there it does indeed not work. Something goes wrong with the build (optimization?), all on win.
ALG: Compared with AOO34 and got it working and not working after compiling VCL with debug; very strange. It has to do with the mbInternalDragGestureRecognizer flag at Window which gets only set when Window::GetDropTarget(), but it seems not to be set reliably for some reason. In ImplHandleMouseEvent in vcl when I force mbInternalDragGestureRecognizer it works. I breaked at where mbInternalDragGestureRecognizer is set to true, but it gets not really set for SvxColorValueSet_docking (where it would need to be set), checking what happens after its construction
ALG: Rebuilt vcl on AOO34 without debug, the D&D from the floating win works again. Strange...
ALG: mbInternalDragGestureRecognizer changes when un/docking the win; win ptr stays and also mpWindowImpl, but mpFrameData changes. It seems to jump between two values for docked and undocked, one with mbInternalDragGestureRecognizer set and one not.
ALG: Change happens in Window::ImplUpdateWindowPtr when DockingWindow::SetFloatingMode is executed (which triggers Window::SetParent). Looks as if mpWindowImpl->mxDNDListenerContainer needs to be reset on SetParent for DockingWindow::SetFloatingMode. SetParent calls GetDropTarget() already, bit it's already set and gets not updated. Trying this...
ALG: Getting closer also in AOO34: Starting undocked makes the next undocked not work. Starting docked makes the 2nd undock not work. Exactly the same in current version, not dependent on debug or not. Looks as if at undock mpWindowImpl->mxDNDListenerContainer needs to be reset to get the correct DropTarget initialized evecy time.
ALG: Added and checked, works as expected. Problem is indeed in undocking, the 2nd time the buffered value mpWindowImpl->mxDNDListenerContainer is already set and gets not new evaluated, thus stays on a wrong value. Preparing commit...
"alg" committed SVN revision 1547026 into trunk: i123765 reset buffered DropTarget when undocking
ALG: Comitted, done.