crosshair coordinates in pcbnew freeze

[Chris Pavlina]

From time to time, the crosshair coordinates in pcbnew become frozen. They do not update in the status bar, and tools act on the frozen coordinates rather than the object actually under the mouse pointer. Selecting the track tool unfreezes them.

Not actually sure whether this happens in legacy as well as GAL - I don't work in legacy enough to notice "time to time" things - but I don't recall ever having noticed it there.

Application: kicad
Version: (2015-07-15 BZR 5963, Git 5bcdea2)-product debug build
wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.2.1,wx containers,compatible with 2.8)
Platform: Linux 4.1.2-2-ARCH x86_64, 64 bit, Little endian, wxGTK
Boost version: 1.58.0
         USE_WX_GRAPHICS_CONTEXT=OFF
         USE_WX_OVERLAY=OFF
         KICAD_SCRIPTING=ON
         KICAD_SCRIPTING_MODULES=ON
         KICAD_SCRIPTING_WXPYTHON=ON
         USE_FP_LIB_TABLE=HARD_CODED_ON
         BUILD_GITHUB_PLUGIN=ON

[Wayne Stambaugh (stambaughw)]

Did you give my middle mouse button patch a try? There is a bug in the
cursor hide/show code when middle mouse button panning. It's easy to
reproduce. Use the middle mouse button to pan until the mouse cursor
leaves the drawing area then let go of the mouse button. The cross hair
will no longer be drawn until you close the window and reopen it. My
patch seems to fix the issue and should in fact fix any other cursor
movement code that cause this issue.

On 7/20/2015 5:08 PM, Chris Pavlina wrote:
> Public bug reported:
>
>>From time to time, the crosshair coordinates in pcbnew become frozen.
> They do not update in the status bar, and tools act on the frozen
> coordinates rather than the object actually under the mouse pointer.
> Selecting the track tool unfreezes them.
>
> Not actually sure whether this happens in legacy as well as GAL - I
> don't work in legacy enough to notice "time to time" things - but I
> don't recall ever having noticed it there.
>
> Application: kicad
> Version: (2015-07-15 BZR 5963, Git 5bcdea2)-product debug build
> wxWidgets: Version 3.0.2 (debug,wchar_t,compiler with C++ ABI 1002,GCC 4.2.1,wx containers,compatible with 2.8)
> Platform: Linux 4.1.2-2-ARCH x86_64, 64 bit, Little endian, wxGTK
> Boost version: 1.58.0
> USE_WX_GRAPHICS_CONTEXT=OFF
> USE_WX_OVERLAY=OFF
> KICAD_SCRIPTING=ON
> KICAD_SCRIPTING_MODULES=ON
> KICAD_SCRIPTING_WXPYTHON=ON
> USE_FP_LIB_TABLE=HARD_CODED_ON
> BUILD_GITHUB_PLUGIN=ON
>
> ** Affects: kicad
> Importance: Undecided
> Status: New
>
>
> ** Tags: cern pcbnew
>

[Chris Pavlina (pavlina-chris)]

I did not try your patch, however, I cannot reproduce the bug the way you said, so I don't think they're related. I'll apply it locally and give it a shot, though.

[Wayne Stambaugh (stambaughw)]

Strange. It's 100% repeatable on windows so maybe its a platform
dependent issue. I'll give Linux a try when I get a chance.

On 7/20/2015 7:48 PM, Chris Pavlina wrote:
> I did not try your patch, however, I cannot reproduce the bug the way
> you said, so I don't think they're related. I'll apply it locally and
> give it a shot, though.
>

[Chris Pavlina (pavlina-chris)]

Well, I've only been working on a layout for half an hour since applying your patch, but it does seem to be fixed. Funny, considering I can't reproduce the other part of your bug.

[Wayne Stambaugh (stambaughw)]

I just confirmed the middle mouse button drag issue appears to be
windows only. This behavior is not present on Linux. It's most likely
a issue with event ordering differences between the two platforms. OSX
most likely has a different event ordering so hopefully someone can get
that tested. Thanks for testing the patch.

On 07/20/2015 08:29 PM, Chris Pavlina wrote:
> Well, I've only been working on a layout for half an hour since applying
> your patch, but it does seem to be fixed. Funny, considering I can't
> reproduce the other part of your bug.
>
> ** Changed in: kicad
> Status: New => Incomplete
>

[Chris Pavlina (pavlina-chris)]

Interesting that even though the issue doesn't exist, the patch fixes another issue...

Marked the bug as "Incomplete" since it's an intermittent issue, I want some more time to be confident that it's fixed. But it does appear to be.

[Chris Pavlina (pavlina-chris)]

> Marked the bug as "Incomplete" since it's an intermittent issue, I want some
> more time to be confident that it's fixed. But it does appear to be.

...which was a good call, as it is not fixed.

[Wayne Stambaugh (stambaughw)]

The patch should fix the problem any time the mouse pointer leaves the
drawing area and then returns. The cross hair counter is reset to zero
which solves the missing cross hair issue. I think wxWidgets is firing
some unexpected events when the mouse leaves the canvas area under
certain conditions that leaves the cross hair visibility counter off by
1. Rather than trying to figure out all of the possible conditions
where this occurs, I cheated and always clear the cross hair counter
when the cursor enters the drawing area. It's ugly but it works every
time as far as I can tell.

On 7/20/2015 10:12 PM, Chris Pavlina wrote:
> Interesting that even though the issue doesn't exist, the patch fixes
> another issue...
>
> Marked the bug as "Incomplete" since it's an intermittent issue, I want
> some more time to be confident that it's fixed. But it does appear to
> be.
>

[Chris Pavlina (pavlina-chris)]

Ah, okay. The problem I'm having doesn't appear to be related to leaving the canvas. It *might* be related to switching tools.

[Chris Pavlina (pavlina-chris)]

Just attached gdb during a cursor freeze and peeked around. Might be useful: WX_VIEW_CONTROLS::m_forceCursorPosition is TRUE at this point. The relevant set point may be pns_tool_base.cpp:219. Perhaps it's not being cleared properly?

[Chris Pavlina (pavlina-chris)]

Also, forcing m_forceCursorPosition to FALSE using gdb "fixes" it, until it breaks again.

[Maciej Suminski (orsonmmz)]

Hi Chris,

You are right, I managed to recreate the problem and I already have a patch that awaits to be committed. I just need to be sure that I did not break anything else, so I think ETA is tonight.

Cheers,
Orson

[Chris Pavlina (pavlina-chris)]

Nice! This bug has been here for a long time, but it got waaaay worse recently, to the point of GAL being nearly unusable for me.