Closed petko closed 9 months ago
Need small demo to reproduce this. In Pascal. Added context-menu to demo_tabs app, for the top tabs, but no effect.
Or can you modify the demo_tabs app for me?
I use C++Builder, so I can't modify the Delphi demo, but this is the code that I am using for showing the context menu:
void __fastcall TForm1::ATTabs1MouseUp(TObject *Sender, TMouseButton Button, TShiftState Shift, int X, int Y)
{
if(Button != mbRight)
{
return;
}
const TPoint pos = ATTabs1->ClientToScreen(TPoint(X, Y));
PopupMenu1->Popup(pos.X, pos.Y);
}
With OnContextPopup
I get the same behavior. I will prepare C++Builder demo for you.
You can download a sample project along with a compiled exe here: https://app.box.com/s/2lz3ru2snub3yia7puls4th1i7vp27yv
made simple fix. it works now in D 10.4.
Works perfectly!
Update: Lately i observed a sporadical revival of this issue.
https://github.com/Alexey-T/ATFlatControls/assets/31130146/a8ba4573-e1fd-4e89-b584-dbae5f974180
‘Sporadical’ does mean: sometimes … especially or mostly if the left click (after popup’s closure) is done near the left boundaries of the tab. This will happen more likely if the tab / tab’s caption is very short … a situation, where obviously it is more likely to navigate near the left boundary of the tab. This happens since I did set DragMode:= dmManual instead of dmAutomatic. Background for that: within #94 i had stated that this issue 94 does only occur when using dmAutomatic, and the belonging fix does query for the dmAutomatic. Obviously I was not fully right here. As afterwards I went back to dmManual, because this appears to be the recommended way. Since then, issue 93 is revived as described and shown in the movie.
tried to repeat sporadical issue in the attabs-demo from ATFlatControls
but cannot repeat it. can you repeat it in the demo?
Can try to do this later the day .. just I tried to reproduce with a simplified project (picked up from some early attempts. The recent attabs files are inside). ATTabs_PageControlEx_sample_upd.zip
with this project of yours, I get access violation in Lazarus 3.99 'main' from git.... i cannot see where the error is...
ok, no access violation now, but your demo uses Windows API and I have Linux. cannot run it.
Oh now, i again forgot to mention; yes, i'm on Win 10 64bit, using the regular new Laz. version Lazarus 3.2 (rev lazarus_3_2) FPC 3.2.2 x86_64-win64-win32/win64).
on Win10 i reproduced the issue. with your demo. what i tried: in OnContextPopup add lines at end
FMouseDown:= false; FMouseDragBegins:= false;
it does not help. i am puzzled.
can you try to revert my last changes about dmAutomatic and check on older code? maybe it will help to make the fix?
1) change
ColorBg := clWindow;
to
ColorBg := clWhite;
to fix painting corner pixels.
2) try this change in
function TATTabs._IsDrag: boolean;
Result:= Dragging and FMouseDragBegins;
for all DragMode variants. seems it is better? but I don't like this solution because of comment in _IsDrag - I will have regression in CudaText
Oh sorry, i’m not so fast … i just could reproduce it with demo_tabs_as_pagecontrol; slightly modified as I don’t have the component installed (files are inside) and I needed to add a popup menu and small dimensioned tabs here. demo_tabs_as_pagecontrol__upd.zip
Now I can do other tests here.
clWhite instead of clWindow would be bad when later using dark mode in the apps, not relevant here, but I’ll keep an eye on those pixels; thanks for the hint!
About 2 now I’ll start.
The original / previous setting
Result:= Dragging and FMouseDragBegins;
for dmAutomatic as well as dmManual does make the problem go away (no wonder, for me that issue didn't exist before).
Of course a regression in CudaText would be serious. Maybe some quite different solution, eg. a separate property or switch might be of help?
for CudaText, new Git code is better because drag-drop of ui-tabs will have red marker when I drag ui-tab to another tab-group. so I want to keep current code. even if red marker shows after click after menu.
Hm, actually such kind of switch is already used (“if DragMode = dmAutomatic”). Only, it’s in fact a bad choosen switch, as you tell “//required Manual”. Something more meaningful or specific could be useful and would allow behavior choice by option. For your use case: something like: “OptDragmodeStrictIndicator” or such??
If not wanted: I’d offer to continue to use “dmAutomatic” (with my personal comment inside about the reason). – A better named switch would allow better understanding though, but no problem, at the end it’s simply a a matter of agreement.
I dont want to make special property for _IsDrag code. this prop will be used only by me in CudaText.
Ok then, so DragMode dmAutomatic would keep to be my solution (as it originally was set since ages for whatever reason). Can be re-closed with this regard. - Great thanks for your attention and all your feedbacks!
I show context menu when the user right-clicks on a tab. However, if the user clicks again on the tab with the left mouse button the drag marker is shown, even though the user was not trying to drag anything. The behavior is new, it was working properly before Oct 30, 2022.
You can see the behavior in this video:
https://github.com/Alexey-T/ATFlatControls/assets/71472/93fdc4c6-aed6-464e-8a7b-11cb109072f6