Prob with DragDrop (unexpected exchange of tabs)? about atflatcontrols HOT 14 CLOSED

Drag-drop was designed only for dmManual value, so I just did not test with dmAutomatic… maybe I will look at it, later ..

from atflatcontrols.

dmAutomatic does work very fine for me for DragDrop of tabs too,, and just without any additional efforts. Except the annoying thing described.

Could you at least apply this simple workaround for to remove the effect?

• instance variable FRightClicked
• within TATTabs.MouseMove, before the line "if OptMouseDragEnabled and FMouseDown" etc.

  if FRightClicked then   // add
     FRightClicked := False // add
  else  // add
  if OptMouseDragEnabled and FMouseDown and (FMouseDownButton=mbLeft) and not _IsDrag then

• And: TATTabs.DoContextPopup, let it start with:
  ` FRightClicked := True;``

from atflatcontrols.

I just tried that change - it doesn't help at all! in my new demo I still see the bug.

from atflatcontrols.

(tested on Ubuntu gtk2)

from atflatcontrols.

Alexey, thank you for you attention!
And on Windows, with dmAutomatic?
I tested with Windows 10 x64, Lazarus 2.2.2 abd Dragmode automatic.

Hm, got unsure now ...
Yesterday i picked up the recent files from github, but didn't test with the demos as they do require to install the package, but i'd prefer to keep the few attab files locally within the app.

So, for verification now i modified the demo_tabs_as_pagecontrol a bit so that id does not need an installed package:. - All needed files are within the zip-file attached:
demo_tabs_as_pagecontrol__test_contextmenu.zip

** Test - without the workaround (deactivate the lines within attabs.pas before)-:
Clixk onto tab 1
Right click onto tab 2
Clixk onto tab 3
---> Tab 3 replaces tab 2. This effect is very confusing
** Same test - using the workaround within attabs.pas -:
Clixk onto tab 1
Right click onto tab 2
Clixk onto tab 3
---> Tab 3 is selected and does stay where it is (expected behaviour)

On Windows, with Lazarus, you don't see the same?

from atflatcontrols.

I don't have access to Windows withing 3-5 days. i tested on Ubuntu gtk2 with dmAutomatic and with your changes-- effect still here

from atflatcontrols.

my test demo-
tst-attabs-dragdrop.zip

from atflatcontrols.

I retried with your test demo (having, this time, registered the package) and the result is the same, on Windows

• issue without the changed lines;
• no issue using the changed lines.

So we'd better wait until you have access to a Windows site for verification, but apparently it's something OS-specific here.

from atflatcontrols.

This fix cannot be used now , if it don’t work on Linux

from atflatcontrols.

Could it be - alternatively to the workaround mentioned - that the following two-liner works on Linux
(on Windows it does the job too) ?

(i'll print it within the context:)

procedure TATTabs.MouseMove(Shift: TShiftState; X, Y: integer);
 ......
  if OptMouseDragEnabled and FMouseDown and (FMouseDownButton=mbLeft) and not _IsDrag then
  begin
    BeginDrag(false, Mouse.DragThreshold);
......
  end;

  FTabIndexOver:= GetTabAt(X, Y, IsX);
  FTabIndexDrop:= FTabIndexOver;

  //  -------------------- try these two lines:
  if  Not (OptMouseDragEnabled and FMouseDown and (FMouseDownButton=mbLeft) and not _IsDrag) then
      FTabIndexDrop :=  cTabIndexNone;

  if FTabIndexOver=cTabIndexNone then exit;

from atflatcontrols.

it fixed the issue but now the normal work is broken. in my last demo I cannot drag. red marker is always after end.

from atflatcontrols.

Oh yes, sorry, my fault!
I tried it a last time and this one seems to prevent the issue and not to break the normal work // Windows:

procedure TATTabs.DoHandleRightClick;
....
begin
  if (FTabIndex=FTabIndexOver) then // to check if click was processed as a valid click on a tab
  begin
    D:= GetTabData(FTabIndex);
    if Assigned(D) and Assigned(D.TabPopupMenu) then
    begin
      P:= ClientToScreen(FMouseDownPnt);
      D.TabPopupMenu.PopUp(P.X, P.Y); 
    end;
    FTabIndexDrop :=  cTabIndexNone;       //  <<<<<<<<<<  this line ADDED <<<<<<<<<<<       
  end;
end;

from atflatcontrols.

seems OK - applied.

from atflatcontrols.

Thank you Alexey! So i think this can be closed now.

from atflatcontrols.