Opened 10 years ago

Closed 17 months ago

#1397 closed defect (fixed)

wxSplitterWindow + wxTextCtrl: Cannot drag split line [GTK2]

Reported by: shaneharper Owned by:
Priority: low Milestone:
Component: wxGTK Version:
Keywords: wxSplitterWindow Cc: shaneharper, hockkn, leio
Blocked By: Blocking:
Patch: no

Description

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).

Attachments (1)

splitter.cpp download (1.5 KB) - added by shaneharper 10 years ago.

Download all attachments as: .zip

Change History (16)

Changed 10 years ago by shaneharper

comment:1 Changed 9 years ago by hockkn

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

comment:2 Changed 9 years ago by 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?

comment:3 Changed 9 years ago by 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...

comment:4 Changed 9 years ago by hockkn

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

comment:5 Changed 6 years ago by wojdyr

  • Status changed from new to confirmed

the bug is still in 2.9-trunk.

comment:6 Changed 6 years ago by wojdyr

  • Keywords wxSplitterWindow added

comment:7 Changed 2 years ago by 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.

comment:8 Changed 2 years ago by 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.

comment:9 Changed 2 years ago by oneeyeman

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

comment:10 follow-up: Changed 2 years ago by vadz

  • Status changed from confirmed to infoneeded_new

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?

comment:11 in reply to: ↑ 10 Changed 2 years ago by oneeyeman

  • Status changed from infoneeded_new to new

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.

comment:12 Changed 17 months ago by 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.

comment:13 Changed 17 months ago by 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;
 }

comment:14 Changed 17 months ago by vadz

  • Status changed from new to confirmed

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.

comment:15 Changed 17 months ago by PC

  • Resolution set to fixed
  • Status changed from confirmed to closed

(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

Note: See TracTickets for help on using tickets.