Author Topic: Strangeness with stepping in debugger using toolbar button  (Read 17915 times)

Offline burtbick

  • Multiple posting newcomer
  • *
  • Posts: 10
Strangeness with stepping in debugger using toolbar button
« on: November 27, 2010, 03:12:44 am »
Hi,

I didn't find any mention of this problem, so maybe it is just something with my configuration.  I'm using the 10.05 version of Codeblocks on Kubuntu 8.04, and the SVN version of 10.05 on Kubuntu 10.04.  Also using the latest CodeBlocks with the bundled MinGW under Windows.  Everything is working well, but I have some strangeness when stepping though code in the debugger using the toolbar button(s) for stepping.  At least on the two Linux installations.  I need to recheck the Windows installation to see if the same issue is there.

Most of the time I can only step one or two lines and then the button doesn't do anything even though it is being clicked on.  If I move the mouse pointer off of the toolbar button and then click the next line button again it steps OK for a single line and then I have to move the mouse pointer off of the button and back on in order to be able to continue stepping.

If I use the key binding to step to the next line F7 in this case there is no problem, I can keep hitting F7 and the debugger always steps one line for each key press.

But if I try to click the corresponding debugger toolbar button multiple times without moving off of the button and back on I get the problem of not being able to step through the code.

Has anyone else seen this problem?  If so did you find a solution for it?  If not do you have any suggestions to try and isolate the cause.  Since it is happening on two different versions of Kubuntu, and two slightly different builds of CodeBlocks I don't think that it is something specific to the version of the OS or CodeBlocks.

I checked the bug reports but didn't see anything like this reported, so I entered a bug report there as well.

Thanks,
Burt

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: Strangeness with stepping in debugger using toolbar button
« Reply #1 on: November 27, 2010, 09:32:07 am »
I can confirm this. This happens to me too all the time.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Strangeness with stepping in debugger using toolbar button
« Reply #2 on: November 27, 2010, 10:33:26 am »
Can you two tell me if this problem happens with debugger's branch version?
Does it depend on the project, because I can't reproduce it with the debugger's branch version?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Strangeness with stepping in debugger using toolbar button
« Reply #3 on: November 27, 2010, 04:46:36 pm »
Can you two tell me if this problem happens with debugger's branch version?
Does it depend on the project, because I can't reproduce it with the debugger's branch version?


Yes, it happens in the debuggers branch. It's been a problem in CB (for me) for a long long time.

For me, it happens when the the cursor accidently hits a variable hidden behind the toolbar and CB wants to popup a tooltip. The tooltip is displayed behind CB (or the toolbar) and cannot be dismissed until the mouse is clicked in some other area of the editor window.

This happens because CB does a SetToolBar(0); Thus, wxWidgets cannot properly report the client area size and location. wxWidgets sees the cursor over a variable, doesn't know it's located behind the toolbars and pops up a (now hidden) tooltip.

Some 10.05 code to adjust for this is:

Code
Index: src/plugins/debuggergdb/debuggergdb.cpp
===================================================================
--- src/plugins/debuggergdb/debuggergdb.cpp (revision 6378)
+++ src/plugins/debuggergdb/debuggergdb.cpp (working copy)
@@ -2672,6 +2672,32 @@
     wxPoint pt;
     pt.x = event.GetX();
     pt.y = event.GetY();
+
+    //(pecan 2009/3/20) begin
+    // Don't eval if cursor is out in unused space
+    if (ed->GetControl()->PositionFromPointClose(pt.x,pt.y) == wxSCI_INVALID_POSITION)
+        return;
+
+    // verify cursor is in the client area
+    wxRect  edRect = ed->GetScreenRect();
+    wxPoint cursScreenPosn = ed->ClientToScreen(pt);
+    wxRect  scintillaRect = ed->GetRect();
+
+    //int fstLine = ed->GetControl()->GetFirstVisibleLine();
+    //int fstLinePos = ed->GetControl()->PositionFromLine(fstLine);
+    //wxPoint fstLinePt = ed->GetControl()->PointFromPosition(fstLinePos);
+
+    edRect.y += (scintillaRect.y>0) ? 10 : 0; //why?
+    for (int i=0; i<3 ;++i )
+        edRect.x += ed->GetControl()->GetMarginWidth(i);
+
+    if (   (cursScreenPosn.x <= edRect.x) or (cursScreenPosn.y <= edRect.y)
+        or (cursScreenPosn.x > (edRect.x + edRect.width))
+        or (cursScreenPosn.y > (edRect.y + edRect.height))
+       )
+        return;
+    //(pecan 2009/06/15) end
+
     int pos = ed->GetControl()->PositionFromPoint(pt);
     int start = ed->GetControl()->WordStartPosition(pos, true);
     int end = ed->GetControl()->WordEndPosition(pos, true);

Commented code lines appear in the fix because I've never been happy with this fix and have experimented over and over again.

It does seem to work for 10.05 however.
I haven't yet adjusted it for the debugger branch.

« Last Edit: November 27, 2010, 10:36:40 pm by Pecan »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Strangeness with stepping in debugger using toolbar button
« Reply #4 on: November 27, 2010, 06:13:07 pm »
I think that a better place for this check is inside cbEditor::OnEditorDwellStart or even in Scintilla.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: Strangeness with stepping in debugger using toolbar button
« Reply #5 on: November 27, 2010, 06:30:36 pm »
good there's already a cause found.

Sometimes I also got a visible tooltip when hovering of one of the debugger toolbar buttons. And that tooltip showed me 'the entire CB screen'.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Strangeness with stepping in debugger using toolbar button
« Reply #6 on: November 27, 2010, 06:52:36 pm »
Sometimes I also got a visible tooltip when hovering of one of the debugger toolbar buttons. And that tooltip showed me 'the entire CB screen'.
I think this is fixed in debuggers branch. I've fixed some tooltip problems
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Strangeness with stepping in debugger using toolbar button
« Reply #7 on: November 27, 2010, 10:14:28 pm »
Sometimes I also got a visible tooltip when hovering of one of the debugger toolbar buttons. And that tooltip showed me 'the entire CB screen'.
I think this is fixed in debuggers branch. I've fixed some tooltip problems


The event described by Killerbot does indeed occur in the debugger branch. A *huge* tooltip displays occasionally when the cursor is just sitting in the tooltip region.

The cause is usually that the cursor is positioned over the toolbar, covering the space at the end of an editor line, is illegal (wxSCI_INVALID_POSITION) and the cursor is seen by wxWidgets as a candidate for a tooltip.

wxWidgets (or Scintilla) should not have considered this position as a candidate. But it could not know, since CB SetToolBar(0). wxWidgets (or Scintilla) sees this as meaning that there is no toolbar to be considered when calculating whether the cursor is in the editors client area.


« Last Edit: November 27, 2010, 10:41:00 pm by Pecan »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Strangeness with stepping in debugger using toolbar button
« Reply #8 on: November 27, 2010, 10:56:01 pm »
wxWidgets (or Scintilla) should not have considered this position as a candidate. But it could not know, since CB SetToolBar(0). wxWidgets (or Scintilla) sees this as meaning that there is no toolbar to be considered when calculating whether the cursor is in the editors client area.
I don't understand... Why would wxScintilla think that it should show tooltips outside of its window? Why does it care if there is toolbar or there is no toolbar? Pretty strange...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: Strangeness with stepping in debugger using toolbar button
« Reply #9 on: November 28, 2010, 03:16:26 am »
wxWidgets (or Scintilla) should not have considered this position as a candidate. But it could not know, since CB SetToolBar(0). wxWidgets (or Scintilla) sees this as meaning that there is no toolbar to be considered when calculating whether the cursor is in the editors client area.
I don't understand... Why would wxScintilla think that it should show tooltips outside of its window? Why does it care if there is toolbar or there is no toolbar? Pretty strange...

wxWidgets uses the size of the toolbar to determine the size of the client area. If it cannot know the size of the toolbar it reports the client area (and thus the Scintilla editor area) as larger than it actually is.

When the tooltip mechanism asks, "am I in the client area?", it's given the wrong answer "yes", even though the cursor is actually in the toobar region.

Quote
wxFrame
A frame is a window whose size and position can (usually) be changed by the user. It usually has thick borders and a title bar, and can optionally contain a menu bar, toolbar and status bar. A frame can contain any window that is not a frame or dialog.

A frame that has a status bar and toolbar created via the CreateStatusBar/CreateToolBar functions manages these windows, and adjusts the value returned by GetClientSize to reflect the remaining size available to application windows.


wxFrame::GetClientAreaOrigin
wxPoint GetClientAreaOrigin() const

Returns the origin of the frame client area (in client coordinates). It may be different from (0, 0) if the frame has a toolbar.

Code in wxFrame:
    // call GetClientAreaOrigin() to take the toolbar into account

Code
void wxFrame::DoSetClientSize(int width, int height)
{
    // leave enough space for the status bar if we have (and show) it
#if wxUSE_STATUSBAR
    wxStatusBar *statbar = GetStatusBar();
    if ( statbar && statbar->IsShown() )
    {
        height += statbar->GetSize().y;
    }
#endif // wxUSE_STATUSBAR

    // call GetClientAreaOrigin() to take the toolbar into account
    wxPoint pt = GetClientAreaOrigin();
    width += pt.x;
    height += pt.y;


Because CB does a SetToolBar(0), any code, including Scintilla or the tooltip code will be given the wrong client area size and origin, thus misunderstanding which region the cursor is in.

My (not so clever) fix tries to compensate for this by guessing the size of the toolbars and subtracting that from the client area. It then verifies if the cursor is actually in the editor client area.

GetClientArea code follows:
Note that when SetToolBar(0) is in effect, the toolbar is *not* subtracted from the reported client area.
 
Code
// get the origin of the client area in the client coordinates
wxPoint wxFrame::GetClientAreaOrigin() const
{
    wxPoint pt = wxTopLevelWindow::GetClientAreaOrigin();

#if wxUSE_TOOLBAR && !defined(__WXUNIVERSAL__) && \
  (!defined(__WXWINCE__) || (_WIN32_WCE >= 400 && !defined(__POCKETPC__) && !defined(__SMARTPHONE__)))
    wxToolBar * const toolbar = GetToolBar();
    if ( toolbar && toolbar->IsShown() )
    {
        const wxSize sizeTB = toolbar->GetSize();

        if ( toolbar->HasFlag(wxTB_TOP) )
        {
            pt.y += sizeTB.y;
        }
        else if ( toolbar->HasFlag(wxTB_LEFT) )
        {
            pt.x += sizeTB.x;
        }
    }


Scintilla Editor.cxx
Code
PRectangle Editor::GetClientRectangle() {
return wMain.GetClientPosition();
}

Code
PRectangle Window::GetClientPosition() {
    if (! wid) return PRectangle();
    wxSize sz = GETWIN(wid)->GetClientSize();
    return  PRectangle(0, 0, sz.x, sz.y);
}

wxFrame
Code
// Get size *available for subwindows* i.e. excluding menu bar, toolbar etc.
void wxFrame::DoGetClientSize(int *x, int *y) const
{
    wxTopLevelWindow::DoGetClientSize(x, y);

    // account for the possible toolbar
    wxPoint pt = GetClientAreaOrigin();
    if ( x )
        *x -= pt.x;

    if ( y )
        *y -= pt.y;

#if wxUSE_TOOLBAR
    wxToolBar * const toolbar = GetToolBar();
    if ( toolbar )
    {
        if ( toolbar->HasFlag(wxTB_RIGHT | wxTB_BOTTOM) )
        {
            const wxSize sizeTB = toolbar->GetSize();
            if ( toolbar->HasFlag(wxTB_RIGHT) )
            {
                if ( x )
                    *x -= sizeTB.x;
            }
            else // wxTB_BOTTOM
            {
                if ( y )
                    *y -= sizeTB.y;
            }
        }
        //else: toolbar already taken into account by GetClientAreaOrigin()
    }
#endif // wxUSE_TOOLBAR
« Last Edit: November 28, 2010, 04:15:04 am by Pecan »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Strangeness with stepping in debugger using toolbar button
« Reply #10 on: November 28, 2010, 01:43:58 pm »
Pecan thanks for the explanation, but I think that you're wrong :)

I've added this code:
Code
    wxPoint pt;
    pt.x = event.GetX();
    pt.y = event.GetY();

    wxRect edRect = ed->GetClientRect();
    wxRect edScreenRect = ed->GetScreenRect();
    Log(wxString::Format(wxT("edRect [%d, %d, %d, %d]"), edRect.x, edRect.y, edRect.width, edRect.height));
    Log(wxString::Format(wxT("edScreenRect [%d, %d, %d, %d]"),
                         edScreenRect.x, edScreenRect.y, edScreenRect.width, edScreenRect.height));
    Log(wxString::Format(wxT("mouse point [%d, %d]"), pt.x, pt.y));

    wxPoint ptReal;
    wxGetMousePosition(&ptReal.x, &ptReal.y);
    Log(wxString::Format(wxT("mouse point real [%d, %d]\n"), ptReal.x, ptReal.y));

And see what I'm getting in the log:
Quote
edRect [0, 0, 1185, 653]
edScreenRect [413, 100, 1185, 653]
mouse point [148, 0]
mouse point real [565, 88]

edRect [0, 0, 1185, 653]
edScreenRect [413, 100, 1185, 653]
mouse point [60, 270]
mouse point real [68, 1068]
As you can see the mouse has moved after wxScintilla has sent the message.
So to properly fix this, we need to check if the mouse is still inside the editor.

Can you try such fix, because I can't reproduce the next button problem, so I can test it?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Strangeness with stepping in debugger using toolbar button
« Reply #11 on: November 28, 2010, 01:51:24 pm »
I just added some debug-messages and
Quote
PRectangle Window::GetClientPosition() {
    if (! wid) return PRectangle();
    wxSize sz = GETWIN(wid)->GetClientSize();
    return  PRectangle(0, 0, sz.x, sz.y);
}
always uses the editor control to determine the client-size and not the MainFrame.
And I was not able to get invalid x and y values, the position was always valid.

The only way to get a debugger tooltip, if the mouse is not placed on visible text, is if the left margin hides text.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Strangeness with stepping in debugger using toolbar button
« Reply #12 on: November 28, 2010, 02:08:19 pm »
As you can see the mouse has moved after wxScintilla has sent the message.
So to properly fix this, we need to check if the mouse is still inside the editor.

Can you try such fix, because I can't reproduce the next button problem, so I can test it?
[/quote]

Before showing the tooltip in gdb_commands.h we check whether the mous is inside the rect that contains the text the tooltip belongs to:
Code
            wxPoint mouse_position;
            ::wxGetMousePosition(&mouse_position.x, &mouse_position.y);

            // We show the tooltip only if the user hasn't moved the mouse.
            if (m_WinRect.Contains(mouse_position))
            {
                s_pWin = new GDBTipWindow((wxWindow*)Manager::Get()->GetAppWindow(), m_What, m_Type, m_Address,
                                          contents, 640, &s_pWin, &m_WinRect);
            }

so either the evaluation of the mouse-position or the Contains-function are wrong.

If you have time to check it, please do so, if not I will do it later.
Time for family now  :D .

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Strangeness with stepping in debugger using toolbar button
« Reply #13 on: November 28, 2010, 02:46:28 pm »
"m_WinRect" is the rect of the selected word/text, so the name is a bit misleading.
And it is possible for this rect to be outside of the window rect of the editor, because there are no checks for this.

Pecan, killerbot: can you add some debug logging and paste the log, when the bug happens?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Strangeness with stepping in debugger using toolbar button
« Reply #14 on: November 28, 2010, 04:18:54 pm »
"m_WinRect" is the rect of the selected word/text, so the name is a bit misleading.
And it is possible for this rect to be outside of the window rect of the editor, because there are no checks for this.

Pecan, killerbot: can you add some debug logging and paste the log, when the bug happens?

What could be done, is make sure, that the points used for the rect are inside the editors window (should not be so hard), but the rect can be very small in this case (if the word is partly invisible).

We can also check whether the mouse is not over one of the left margins (in OnDwellStart), so we can avoid possible problems here, too.

I sometimes also had the same problem and the only way out is to kill gdb and/or the codeblocks into it, and what's more the mouse does not work properly in this case.

But I have debugger tooltips disabled, so the problems seems to be at another place (or there are more possible issues).

We had similar problems (leads to a hang on wxGTK or a crash on windows) due to t a not properly released mouse capture.
I fixrd it by a forced MouseRelease before the modal dialog, that asks whether a changed file should be reloaded was shown.
See this commit: http://svn.berlios.de/wsvn/codeblocks/trunk/src/sdk/editormanager.cpp?op=diff&rev=6845 .