wxSplitterWindow + wxTextCtrl: Cannot drag split line [GTK2]

[shaneharper]

Attempting to drag the split line sometimes fails when
a cursor indicating that the mouse pointer is over the
split line is shown.

Removing the border from the wxTextCtrl (by using the
wxNO_BORDER style) "fixes" the problem, although it
should be possible for the splitter to function
correctly when the wxTextCtrl has a border (which it
has by the default).

[hockkn]

I am amazed to report that this bug is still occuring on
current CVS.

[hockkn]

Mart, what is the meaning of "Accepted" in this case? I
don't see any note indicating a change nor a recent commit.

If you tried it and couldn't reproduce it, what

configurations did you try?

[leio]

It's a bug entry. The bug is in a state of being "accepted".
That is the bug is confirmed by a bug tracker
moderator/developer to be not invalid and henceforth the bug
report has been accepted.
That's what I think it means.
The name "Resolution" is kind of vague for the group. There
are also entries like "Remind" and "Later" in there.
Just trying to make better use of what we have for our bug
tracking. I believe a bugzilla site would be much better.
Now if I only could search the sf.net bugs database based on
resolution settings...

[hockkn]

Ah, OK. A new approach AFAIK but sensible. Thanks for the
explanation.

[wojdyr]

the bug is still in 2.9-trunk.

[oneeyeman]

I just tested the program supplied on my system - Linux wxGTK from about a month ago and GTK+ 2.24+.
The bug is still present, however I am not sure it is a bug.
When you create a text control with a border it means that when the mouse is placed over that border it should change to become an arrow as if you tried to re-size the control. However the next control is a sash which should handle all resizing.

I can re-confirm this observation by putting an extra control in between.

[oneeyeman]

Well running the program under gdb I see that when setting the breakpoint on the OnMouseEvent() function "if( event.LeftDown()" line the program does not stop in this case.

[oneeyeman]

Can anybody else reproduce this?
If not then per Vadim testing this should be closed.

[vadz]

I don't understand anything in this bug :-( You say that you see it yourself yet you want it to be closed?

Could you please clarify? In particular, which problem exactly did you observe in comment:7? What does adding an extra control (code/patch?) does?

[oneeyeman]

Vadim,
Replying to vadz:

I don't understand anything in this bug :-( You say that you see it yourself yet you want it to be closed?

Sorry, I mixed 2 tickets. Or maybe I forgot.

Could you please clarify? In particular, which problem exactly did you observe in comment:7? What does adding an extra control (code/patch?) does?

Ok, when running attached code, you will see the splitter window. On top there will be a text control.
When you move the mouse on the splitter area and try the drag'n'drop the splitter everything work as expected.
However, if you move the mouse and immediately when the cursor turns to up-down arrow you will try to do DnD operation nothing will happen. My guess is that the border is no counted on the size of the control. I barely remember the discussion on wx-dev about the border and size calculation but don't remember the outcome.

[oneeyeman]

Hi, Paul, Vadim,
I made a small video (~2MB) of me reproducing the issue, since Vadim was not able to reproduce it.
Since the video file is big and it's not possible to attach, please tell me where to put it and I will upload the file on the web for you to see.

[pcor]

Easily reproducible with the sample provided 9(!) years ago, if you can manage to move your mouse one pixel at a time. The immediate cause is that on wxGTK a mouse leave event occurs when the pointer leaves the client area, rather than when it leaves the outside border of the window. That is not really correct, but it looks very hard to fix.

But I think this is just exposing flaws in SashHitTest(). The "tolerance" parameter seems bogus to me, there won't be mouse events for the sash unless the mouse is on the sash, so what is the point of a fudge factor? And the sash size computation is off by one. The following patch fixes the problem, but I think the tolerance parameter should be removed.

Index: src/generic/splitter.cpp
===================================================================
--- src/generic/splitter.cpp	(revision 73107)
+++ src/generic/splitter.cpp	(working copy)
@@ -323,7 +323,7 @@
     }  // left up && dragging
     else if ((event.Moving() || event.Leaving() || event.Entering()) && (m_dragMode == wxSPLIT_DRAG_NONE))
     {
-        if ( event.Leaving() || !SashHitTest(x, y) )
+        if ( event.Leaving() || !SashHitTest(x, y, 0) )
             OnLeaveSash();
         else
             OnEnterSash();
@@ -491,7 +491,7 @@
 
     int z = m_splitMode == wxSPLIT_VERTICAL ? x : y;
     int hitMin = m_sashPosition - tolerance;
-    int hitMax = m_sashPosition + GetSashSize() + tolerance;
+    int hitMax = m_sashPosition + GetSashSize() - 1 + tolerance;
 
     return z >=  hitMin && z <= hitMax;
 }

[vadz]

I agree that the tolerance parameter doesn't seem to make much sense. But, just in case it is, I'd prefer to commit the first chunk of your patch above first to really fix this bug and then remove tolerance with a separate commit just in case we ever need to restore it later because, AFAICS, with the fix in the event.Leaving() line, it should at least do no harm any more.

[PC]

(In [73110]) Avoid setting sash resize cursor when mouse is still over border of second pane with wxGTK
This made it possible to have the resize cursor, but not be able to drag the
sash, and happened because wxGTK sends a leave event when mouse leaves client
area instead of outer border of window. Setting the useless SashHitTest()
"tolerance" parameter to zero avoids the problem.
Fixes #1397