The 10 January 2006 build is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml
A link to the unicode windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26u_gcc_cb.7z

The 10 January 2006 build is out.
  - Windows : http://download.berlios.de/codeblocks/CB_10jan2006_rev1707_win32.7z
  - Linux : not supported yet


Resolved Fixed:

• KeyBinder:0.4.6 Rebuild menuitems with misaligned bitmaps and accelerators
• Minor modifications to remove some warnings when compiling wxPdfDocument with -Wall
• Converted ToDoList from message log to docking window
• Added menu "View->To-Do list"
• Converted menus "Debug->Debugging windows->*" to checkable
• Compiler errors don't highlight the whole line with the ugly orange color anymore. Instead, a red mark is used in the margin
• Removed obsolete editor's color settings (like "compiler error")
• Updated wxScintilla to version 1.67
• Fixed the crash-before-exit in linux


• Add new files to recent list (patch #1402078)(bug : 1401383)
• Upgraded wxAUI to 0.9.1 (partial patch #1402085)
• Added wxAUI as a dependency of src in the unix project file
• Fix for recent files/projects lists to always display the full filename (patch #1402109) (bug : 1401379)

• Manager framework redesign
  - No more ManagerProxy
  - Manager::Get() is a lot less expensive than it was before
  - Manager::Get() never returns an invalid pointer, the same is true for Manager::GetConfigManager.
  - All other managers are initialised when they are first referenced and deinitialised in order of dependence during shutdown.
  - The Manager::GetXXX functions will not automatically return null while the application is shutting down. Instead, a valid pointer is returned as long as the respective manager is available, null thereafter.
  - Plugins are freed before most core managers (for example EditorManager, ProjectManager, and MessageManager) shut down, so there can never be an invalid pointer for these.
  - The status of all managers can be verified using the static ManagerXXX::Valid() function.
  - PersonalityManager correctly works for the --profile=ask option now (showing a list of available profiles)

Regressions/Confirmed/Annoying/Common bugs:

• DDE bug : clicking in windows explorer on a CB registered file throws an error message box
• toolbar-images-not-changing-state (is a wx problem)

[280Z28]

What do you mean by "# toolbar-images-not-changing-state (is a wx problem)"

[killerbot]

It was artoj who asked me this to add to the list, and I remember a little bit seeing some discussions in other topics about this. I don't know 100% the problem.

@artoj : could you please explain again the problem

[280Z28]

It was artoj who asked me this to add to the list, and I remember a little bit seeing some discussions in other topics about this. I don't know 100% the problem.

@artoj : could you please explain again the problem

If it has to do with the fact that the Abort button on the debugger toolbar doesn't go gray when it's disabled.... omg I tried to make that work but dang...

[Michael]

It was not what was discussed here?

Michael

[artoj]

It was not what was discussed here?

Yup, that's the one.

The affected buttons are (at least): save, print, find, replace and abort debug.

save - image always enabled
print - image always disabled
find - image always enabled
replace - image always enabled
abort debug - image always enabled

-----------

Could someone with proper rights to the SF.net project page close these bugs because they are now fixed:

1401383 
1401376

Thanks for killerbot for creating the patches (and devs for applying them).

[artoj]

I've posted the following bug to the tracker:

1. Launch Code::Blocks.
2. Create new project (File -> New project...)
3. Select Console application (or other project type). Select "C:\" (or other drive root directory) as the directory where to create files. Type name for the project.
4. Press OK. The project creation fails.

#1403023 Project creation to drive root fails (nightly)

[artoj]

And next:

1. Open CodeBlocks and create new file (File -> New).
2. Minimize CodeBlocks.
3. Open the new file in external editor (such as Notepad).
4. Edit the file in Notepad and save changes you made.
5. Press the CodeBlocks button in the Taskbar to maximize CodeBlocks.
6. The file is changed but no reload file dialog is shown.

#1403064 File modifications outside CB -notification fails (nighly)

[thomas]

I can confirm the bug in the 1717 build which I use to work with (fully optimized, stripped).

However, I was NOT able to reproduce it in the non-optimized, non-stripped 1717 build.  :?

[artoj]

I can confirm the bug in the 1717 build which I use to work with (fully optimized, stripped).

However, I was NOT able to reproduce it in the non-optimized, non-stripped 1717 build.  :?

Hmm...

@killerbot, what build flags do you use in the nightly builds?

[killerbot]

I use the cbp files, so that means several of them have debug info, non optimized, and during the update phase the debug info get's stripped off.

[Michael]

I have remarked another small issue (or may be it is just my crazy notebook ).

When I select some text and I wish to move it, the arrow with the small rectangle appears, but when I click to put the text in the new position, it does not work :?. So, I have to press "Esc" to re-use C::B.

Has someone else remarked this problem?

Michael

[EDIT]: It seems it was just a local problem (i.e., my crazy notebook strikes again ). After a new re-start, it works. Anyway, I have remarked that it do not put the text exactly where I would like, but just a line above :?.

[artoj]

I use the cbp files, so that means several of them have debug info, non optimized, and during the update phase the debug info get's stripped off.

OK, thanks.

So I can produce the bug with non-optimized build.

When I select some text and I wish to move it, the arrow with the small rectangle appears, but when I click to put the text in the new position, it does not work :?. So, I have to press "Esc" to re-use C::B.

Has someone else remarked this problem?

Sorry, I can't reproduce it.

[Michael]

When I select some text and I wish to move it, the arrow with the small rectangle appears, but when I click to put the text in the new position, it does not work :?. So, I have to press "Esc" to re-use C::B.

Has someone else remarked this problem?

Sorry, I can't reproduce it.

Sorry, just my fault :oops:. See my EDIT above.

Michael

[artoj]

OK, I have found another bug (it's bit hard to reproduce, it needs quick mouse hand)

1. Launch Code::Blocks and load the default layout (I'm using the default default layout, nothing changed).
2. Drag the management window so it will undock.
3. Dock the management window again to its default place.
4. Minimize Code::Blocks.
5. When Code::Blocks is minimizing quickly press the Code::Blocks taskbar button. You have to hit it before Code::Blocks is fully minimized. If you did it right Code::Blocks will be unrestoreable from the taskbar by pressing the taskbar button (you can actually restore it by right clicking the taskbar icon with mouse and selecting Restore).

This unrestoreable state only happens if you move the docking windows around.