The 12.11 RC1 (11 November 2012 build 8549) is out.

[dmoore]

I can't actually replicate the issue... What is the problem that this is solving? (and how do I reproduce?)

- have a project with many files (with dummy content)
- run a "Replace in files" operation
- make sure things get replaces and e.g. editors are open whose content is updated
-> after the operation has finished (and editors were opened) C::B seems like "dead", an UI refresh seems missing.

Thanks. I can replicate the issue but the patch doesn't appear to fix. (Perhaps opening the new window while the UI is frozen causes a problem with something like AUI?) Why do we need to freeze the app anyway?

[Folco]

When I run a project from CB (the green arrow in the compiler toolbar), and that I kill this program, I can't stop the debuger anymore.
I get that :

The red cross of the compiler toolbar doesn't work, and the icons of the dbg one bring the dialog box you see.
The only way to stop the debuger is to stop CB.

I get that with Win 7 64b, MinGW (not the one provided with CB) and gcc 4.7.2.

[MortenMacFly]

Why do we need to freeze the app anyway?

Yes, that came to my mind, too. Initially it was done to speed up things - but I think a Hide() / Show() call instead might be better... Can you try tat?

[raynebc]

Since it's been this way for a while, I figured I'd mention it since this is a release candidate:  Often, I notice that when building my project, the build log display doesn't refresh properly, I have to toggle it off and then back on with F2 and then it will display its progress.

[dmoore]

Why do we need to freeze the app anyway?

Yes, that came to my mind, too. Initially it was done to speed up things - but I think a Hide() / Show() call instead might be better... Can you try tat?

It works but it's a little weird visually to have the app disapper then come back. (Just dropping the Freeze/Thaw also works, but I guess it could be really slow if there were a huge number of changes)

Changing topic: opening and closing the CB project file is still slow as molasses... Are we not touching this until after release?

[raynebc]

I've also noticed that if the cursor is not close enough to the center of the visible portion of the file window (ie. no more than 4 lines away from the top/bottom), pressing any of various keys (SHIFT, ALT, CTRL, CAPS_LOCK) causes the window to scroll one line at a time moving the cursor toward the center of the screen.  Is this a feature I can turn off?

[Folco]

Same bug here (Win 7 64b), but not on Linux (Squeeze, Jens'packages).

[oBFusCATed]

What file window are you talking about?

[Folco]

The edition window.
1. Put the edition cursor somewhere in the editing zone
2. Scroll up to make the cursor disappear at the bottom of the screen
3. Press the Ctrl key, it should scroll down line-by-line until the cursor appears in the editing zone

[oBFusCATed]

Doesn't happen to me, I'm using the latest rev on Linux. 

[Folco]

Cf. http://forums.codeblocks.org/index.php/topic,17070.msg117151.html#msg117151
Seems to be Win only.

[Alpha]

I've also noticed that if the cursor is not close enough to the center of the visible portion of the file window (ie. no more than 4 lines away from the top/bottom), pressing any of various keys (SHIFT, ALT, CTRL, CAPS_LOCK) causes the window to scroll one line at a time moving the cursor toward the center of the screen.  Is this a feature I can turn off?

The EditorTweaks plugin tries to keep the position in the editor away from the edges. It scrolls one line up/down (when needed) based on a calculation every keypress.  Disabling the EditorTweaks plugin is currently the only method to turn off this check.

The edition window.
1. Put the edition cursor somewhere in the editing zone
2. Scroll up to make the cursor disappear at the bottom of the screen
3. Press the Ctrl key, it should scroll down line-by-line until the cursor appears in the editing zone

This has already been fixed in the trunk, see revision 8580.

Doesn't happen to me, I'm using the latest rev on Linux. 

Which is why you would not see it in the latest revision .

[dmoore]

I've also noticed that if the cursor is not close enough to the center of the visible portion of the file window (ie. no more than 4 lines away from the top/bottom), pressing any of various keys (SHIFT, ALT, CTRL, CAPS_LOCK) causes the window to scroll one line at a time moving the cursor toward the center of the screen.  Is this a feature I can turn off?

The EditorTweaks plugin tries to keep the position in the editor away from the edges. It scrolls one line up/down (when needed) based on a calculation every keypress.  Disabling the EditorTweaks plugin is currently the only method to turn off this check.

What is this?

[Alpha]

Patch 3354 added this action.  Try typing a bunch of new lines, or holding backspace to delete a bunch of lines, or moving the caret with the arrow keys.  (Assuming EditorTweaks is enabled) the editor will scroll every time you get close to the top/bottom, so that a buffer of several lines of text will always be visible (so you can see the upcoming context, and are never working blindly on the bottom line of the editor).

[dmoore]

Patch 3354 added this action.  Try typing a bunch of new lines, or holding backspace to delete a bunch of lines, or moving the caret with the arrow keys.  (Assuming EditorTweaks is enabled) the editor will scroll every time you get close to the top/bottom, so that a buffer of several lines of text will always be visible (so you can see the upcoming context, and are never working blindly on the bottom line of the editor).

So judging by the complaints it would be better if it (a) only responded to key presses that add or remove characters in the editor, and/or (b) had a menu toggle?