User forums > Using Code::Blocks

build completion changes focus when typing

(1/2) > >>

mingkoonkat:

Hi,

My code blocks installation (13.12) abruptly changes the keyboard focus to the source file window of the first compile error when the build completes.

This behavior can get a little bit taxing on my productivity for several reasons.

1) I am typing away in source file A when the build completes asynchronously, and I end up typing into source file B and inadvertently damaging it.
2) After running many builds, on a large package of source files, the number of source files open in the editor grows to a huge number and I must either close all source files that are open or close each of the files that I didn't open one-by-one manually.
3) Frequently the first compiler error in the build isn't the one I am working on and I don't like to change the window focus away from what I am working on because I must search through all of the huge number of files that are open to find my place again. This gets to be a bit  taxing because the tab of the file I am working on is often no longer visible on the screen because there are now so many files open.

Therefore I am hoping for an option to control this keyboard, and or window, refocus behavior at the end of a build, but cant find anything after many searches through the configuration options.

I do use custom "make commands" in the "project build options" dialog box to run our gnu make based build system. So perhaps only users in that mode of operation experience this issue?

Thanks for code blocks BTW, which I do like very much and so I always hope for new enhancements!

PS: There are also some issues with the debugger command line window. Whenever a break point is hit the keyboard is abruptly yanked away from the gdb command line box and we end up typing into a source file where the break point is set. Also no cut and paste within the gdb command line window. Also, gdb has a very nice command line feature where a <CR> causes the last command typed to be repeated (such as when we have many single step instruction commands one after another), but this maybe doesn't work in C::B gdb command line window.

PPS: I notice that the scrolling of the build messages only in the Linux version of C :: B gets slower and slower over time and I must periodically restart C::B to stay productive. I don't know if this has to do with the number of open files that accumulate or some other issue.

stahta01:
I am guessing that when the build finishes the "build message" get automatically set as being in focus/selected window.
I would also like to suggest a feature to prevent this from happening.

Tim S.
 

oBFusCATed:
C::B tries to be smart an goes to the first error, this is useful most of the time because you can fix it straight away.
I don't know what kind of broken project you are working on (where you are editing one file and it fails in another), but I don't see what can be done about it.
This is not related to the custom make file. It will happen if you use the native build system.
You could try to patch it in a way that suits you and show the patch to us, so we can consider integrating it.

I hope you've set Settings -> Editor -> General -> Other settings -> Editor's name is file's  to name only (no path information)!
I also hope you not using step, next of similar commands in the debugger's command line, it is not intended for this kind of commands and they'll mess the debugging pretty much. We have tool buttons, menu items and shortcuts for them.
Except for the cut-paste problem, the other issues are expected and won't be improved much. The cut-paste is tough because wxGTK is behaving strange and wx people don't think this strangeness is a problem.

For the slow down, please use perf or other profiler and show the backtrace. I don't think I've seen it slow down.

mingkoonkat:

> C::B tries to be smart an goes to the first error, this is useful most of the time

IMHO, a GUI designer should be very careful about insisting on asynchronously yanking the keyboard focus. That policy might be appealing with nubees, but will be less popular with seasoned users. For example, it can be vexing for users that try to work in parallel with the build in C::B. The build can take longer on large projects. I'm certain that MSVC doesn't asynchronously yank the focus. I suspect you will find the same policy is implemented with other IDEs that have a large installed base.

> I hope you've set Settings -> Editor -> General -> Other settings -> Editor's name is file's  to name only (no path information)!

Just now made this change, thanks.

> For the slow down, please use perf or other profiler and show the backtrace. I don't think I've seen it slow down.

This is ubuntu running as vmware guest nested in windows so graphics performance is maybe suboptimal. Nevertheless, I notice that restarting C::B seems to fix the issue. I will try to grab some traces when I have some time.

> I also hope you not using step, next of similar commands in the debugger's command line, it is not intended for this kind of commands and they'll
> mess the debugging pretty much.

I have definitely  experienced this issue, it hangs up the GUI sometimes, and the only resolution is to kill C::B. Its easy to make this mistake if you are also a gdb command line user. I don't seem to recall experiencing this type of issues with other gdb debugger wrapper GUIs such as DDD, or the sun microsystems debugger. They must have arrived at a solution for tracking the internal state of the debugger in the gui, but unfortunately I cant make any suggestions. Its easier to whine than actually fix it DYN.

mingkoonkat:
Furthermore for developers working on broken projects employing templates in the c++ std library, a small issue in the developers code can generate a copious output from the compiler, and often the first error points to a header in the c++ std library which invariably isnt the root cause.

Yanking the focus to the first error often disrupts what the developer is looking at, and sends the IDE to another header. The developer is obliged to sort through all of the files that are open so he can resume with looking at what he was concentrating on.

Navigation

[0] Message Index

[#] Next page