News:

When registered with our forums, feel free to send a "here I am" post here to differ human beings from SPAM bots.

Main Menu

BrowseTracker dialog is not closing

Started by darmar, December 20, 2020, 03:22:12 PM

Previous topic - Next topic

darmar

I have problem with BrowseTracker plugin:
when I Alt+Left, BrowseTracker dialog is shown. However it remains shown when I release Alt key. I have to double-click on the file name to close the dialog.

I use my custom build of C::B: Ubuntu, latest wxWidgets (I tried with v3.1.4 and latest Git), GTK 3.

Do somebody have had such problem?

I searched for the source of the problem. I found, that events wxEVT_KEY_DOWN and wxEVT_KEY_UP are not captured somehow. Therefore in BrowseSelector.cpp I connected 'm_panel' instead of 'm_listBox':

    - m_listBox->Connect(wxID_ANY, wxEVT_KEY_UP, wxKeyEventHandler(BrowseSelector::OnKeyUp), NULL, this);
    - m_listBox->Connect(wxID_ANY, wxEVT_KEY_DOWN, wxKeyEventHandler(BrowseSelector::OnKeyDown), NULL, this);
    + m_panel->Connect(wxID_ANY, wxEVT_KEY_UP, wxKeyEventHandler(BrowseSelector::OnKeyUp), NULL, this);
    + m_panel->Connect(wxID_ANY, wxEVT_KEY_DOWN, wxKeyEventHandler(BrowseSelector::OnKeyDown), NULL, this);

Now plugin works as is expected. However, I am unsure, if this solution will work on all platforms.

Pecan

I'll have a look at it. Thanks for the suggestions.

Pecan

Fixed svn 12254
Missing GetEventHandler()'s

darmar


darmar

I tried to understand why the GetEventHandler() call in the patch is required. And I couldn't. Could you @Pecan explain it?

darmar

I just recompiled C::B with SVN 12270. The problem still there: the BrowseTracker dialog remains opened.

stahta01

Quote from: darmar on December 26, 2020, 09:50:42 AM
I tried to understand why the GetEventHandler() call in the patch is required. And I couldn't. Could you @Pecan explain it?

In an recent, wxWdgets upgrade likely 2.8 to 3.0 or maybe 3.0 to 3.1 the event handling system was changed and it is recommended or required to use  GetEventHandler() call for proper event handling. I could be wrong about that since I am not an wxWidgets programmer; but, I have upgraded a few wxWidgets projects to either 3.1 or 3.0.

https://docs.wxwidgets.org/trunk/overview_events.html

Tim S.
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

Pecan

#7
I'll revisit the problem. I think it's because the dialog does not get or looses focus.

Are you running your os with focus-follows-mouse?

darmar

Thank you, @stahta01, for the reply.

@Pecan:
QuoteAre you running your os with focus-follows-mouse?

I looked into Tweaks. There is selected option "Click to focus". I haven't changed this option since OS install.

Pecan

@darmar

Could you tell me how exactly to create this situation?
I'm having problem reproducing it.

What keys or sequence of keys do you use?
thanks


darmar

Thank you for taking your time to investigate this issue. I guess there aren't many users who try to compile and use C::B with the latest wxWidgets on Linux. There are no C::B project files for wx3.1.* too. If you can't reproduce this problem, then, perhaps, is better to wait. I can live with the 'temporal' solution I described.

QuoteWhat keys or sequence of keys do you use?

I use default  key combination: Alt+Left or Alt+Right. And after that, the dialog remains opened.

Pecan

Quote from: darmar on December 29, 2020, 01:35:04 PM
QuoteWhat keys or sequence of keys do you use?

I use default  key combination: Alt+Left or Alt+Right. And after that, the dialog remains opened.

Until I can find a fix, you can also use Ctrl-tab to switch between editors. The key combination is built in (hard coded) already.

Pecan

I'm finding this problem in more than just the dialog in Browsetracker.

One time out of 10, some CB dialogs like find-in-files appear with no focus. Even the esc key won't dismiss them. the dialog is disabled until I move the mouse into the dialog, it then works as expected.

Is anyone else experiencing this problem?

oBFusCATed

Yes, I think I see this on some small dialogs with wx+gtk2. The dialogs are disabled until I move the mouse outside and back inside the dialog.
(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!]

Pecan

#14
Quote from: oBFusCATed on January 01, 2021, 03:06:06 AM
Yes, I think I see this on some small dialogs with wx+gtk2. The dialogs are disabled until I move the mouse outside and back inside the dialog.

Thanks, I'll start tracking this down.
I'd appreciate any suggestions from anyone about where to start looking.

Please tell me what OS,  wxWidgets and CB version you're running.
Also, for those not experiencing the problem, please tell us the same so we can narrow the field.