News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

BrowseTracker dialog is not closing

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

Previous topic - Next topic

darmar

I just a bit played with the code and found that uncommenting the last line in function BrowseSelector::Create enables BrowseTracker to function properly:

  -  //?m_listBox->SetFocus();
+  m_listBox->SetFocus();

It seems that some developer had this problem and solved it earlier. Can someone try it?

darmar

QuoteUntil I can find a fix, you can also use Ctrl-tab to switch between editors.

I tried Ctrl-tab on Official C::B 20.03, Ubuntu 20.04. It doesn't function. The same situation with the newest wxGtk3. As Pecan already told, there are more problems with getting the focus.

oBFusCATed

#17
On linux it is ctrl+,
Ctrl+Tab has never worked, because gtk doesn't allow to override its meaning.

edit: s/it/its/
(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!]

darmar

Thank you, oBFusCATed. Ctrl+, works perfectly!

Pecan

#19
Quote from: darmar on January 07, 2021, 09:00:59 PM
I just a bit played with the code and found that uncommenting the last line in function BrowseSelector::Create enables BrowseTracker to function properly:

  -  //?m_listBox->SetFocus();
+  m_listBox->SetFocus();

It seems that some developer had this problem and solved it earlier. Can someone try it?

I too have tried this change. It helps a little bit, but I still get freezes in both Find-in-files dlg and BrowseSelector dig.

The symptoms are: the main window always gets the focus when the freeze occurs, but any mouse click causes the focus to shift to the correct dialog item.

There are complaints about this problem to wxWidgets going back 8 years. A fix from wxWidgets solves that particular problem but not all.

I have found this problem as far back as wx2.8.12 (the oldest CB in my archive).

It seems to be related to the delayed focus method used in wxWidgets and the failure of some wxEventFocus handler to event.Skip() either EVT_Set_FOCUS, EVT_KILL_FOCUS or wxIdle event.

I've viewed all event handlers in CB for that problem and have not found it in either the core or the plugins that I use.

I'm still looking.


Pecan

Fixed rev12470. Shamelessly gloaming the editor managers wxSwitcher.
 

oBFusCATed

Can you post what is the problem, what is casing the problem and how you've fixed it? "* BrowseTracker - Fixed editor switching dialog" as a commit message is rather vague.
(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

@oBFusCATed

The problem was the same as many of the other small dialogs.
wxWidgets never gives the dialog the focus.
So it just sits there until the user clicks inside the dialog window.

This happens often with "Find/Find in files", and other dialogs requesting just a yes or no response.

I spent may weeks trying to find the problem, but gave up.
It appears (I can't catch it) that wxWidgets tries to find the first widget in the diaglog and give it the focus. But it misses and gives the parent the focus instead.

I used the editors wxSwitcher code to solve the Browsetracker problem.
It works.


oBFusCATed

Have you talked to the wx people about the problem? I don't see a reason for us to workaround a wx problem or to workaround a problem we might cause with some other workaround.
(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!]