The 23 february 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
For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://download.berlios.de/codeblocks/mingwm10.7z

For support of ansi builds, a link to the ansi windows wxWidget dll for Code::Blocks : http://download.berlios.de/codeblocks/wxmsw26_gcc_cb.7z

The 23 February 2006 build is out.
  - Windows : http://download.berlios.de/codeblocks/CB_20060223_rev2068_win32.7z
  - Linux : not supported yet


Resolved Fixed:

• Fixed a serious flaw in event notifications
• Updated all XRC resources (and respective dialogs) in sdk/ and src/ to use wxStdDialogButtonSizer where applicable
• fixed potential problem with multi inclusion protection of cbeditor.h (patch 855)
• Added dummy virtual destructor in ProjectLoaderHooks::HookFunctorBase to keep the compiler happy
• Changed the function signature for ProjectLoaderHooks::HookFunctorBase::Call(): added the project in question as first argument
• Fixed bug #6467: Source Formatter (AStyle) delete lines automatically
• Exporter : Now using cbU2C
• Fixed: HTMLExporter wasn't setting the page title correctly

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)

[jimshen]

Fixed bug #6467: Source Formatter (AStyle) delete lines automatically

thank you very much.

[Ceniza]

You're welcome

[Conan Kudo]

Where are the bug lists?

[Ceniza]

http://developer.berlios.de/bugs/?group_id=5358?

[skirby]

Hello,

I noticed a nasty bug which make C::B crash.
It is in the bugs list (ID 006562) but I know how to reproduce it systematically.
You can easily reproduce it.
Open a project. It must contains at least one .cpp file and its associated .h file (ex: main.cpp, functions.cpp, functions.h)
Remove from project the cpp file (with right click and "Remove file from project")
Now remove the associated .h with the same method.
C::B crash 

I hope you could fix it.
Fortunately, you can remove the .h and after remove the .cpp without problem.

Have a nice day

[Michael]

I noticed a nasty bug which make C::B crash.
It is in the bugs list (ID 006562) but I know how to reproduce it systematically.
You can easily reproduce it.
Open a project. It must contains at least one .cpp file and its associated .h file (ex: main.cpp, functions.cpp, functions.h)
Remove from project the cpp file (with right click and "Remove file from project")
Now remove the associated .h with the same method.

Yes, I have remarked this problem too. Anyway, for me it was, e.g., when I removed several .h files from my project. The same occured by removing .cpp files. Anyway, the number of removed files was most of the time different.

I have posted about this sometime ago.

Fortunately, you can remove the .h and after remove the .cpp without problem.

I am not sure about this.

Best wishes,
Michael

[killerbot]

just saw this commit from our Don Corleone :

Fixed occasional crash when removing files from a project (bug #006562)

[Michael]

just saw this commit from our Don Corleone :

Fixed occasional crash when removing files from a project (bug #006562)

Yes, I have noticed it sometime ago, built C:B, tested it and...the remove file from project is working fine now. That's good and fast work .

Best wishes,
Michael

[royalbox]

There's something that drives me mad with recent nightly builds, though I don't know which was the first version that introduced it.

You want to select a block of code so you put your mouse on the left edge, the arrow cursor points the other way, you press the left mouse button ready to start selecting the text and the block of code folds. I think it would be better if the code only folded when you click on the + and -.

Other than that, and the fact that the aStyle option; 'don't break a block of code on a single line' doesn't seem to work, it's getting better every day.

[mandrav]

You want to select a block of code so you put your mouse on the left edge, the arrow cursor points the other way, you press the left mouse button ready to start selecting the text and the block of code folds. I think it would be better if the code only folded when you click on the + and -.

This was like this forever. It's normal editor's behaviour.
If you want to select a line, move your pointer over the line numbers.

[Conan Kudo]

There is only two bugs left on the list??? You guys must be working fast! Unfortunately the "annoying problems" like the DDE error and the wxWidgets not-changing-state icons have less to do with the program, so is the 1.0 release going to be held up because of them?

[killerbot]

this is not the only list though :
- there's still a list at sourceforge (access to it has been blocked)
- new list at berlios

The list in here, it one that came back in several posts, this list can be used in a more clever way.
See the firefox nightlies on a better usage. But then for every artefact people should create bug reports, today to many things are just being handled in the forum. Someone detects something, and developers almost directly fix it. This is off course very nice, on the other hand you have less overview on aal artefacts/defects/bugs/ ....

[royalbox]

If you want to select a line, move your pointer over the line numbers.

Right, thanks. I don't like having line numbers so that's probably why it's more tricky. I don't remember this in RC2 but you would know better than me.

I forgot to mention code completion which I think is still a long way from being very useful. I find that it doesn't pop-up when I would expect it to, and if it does pop up then it gives too many options. For instance, where you'd expect a range of enum values, you get all the methods and variables as well. Too confusing to be useful and I end up going to the file where the enum is defined and copying and pasting the value.

Maybe coming from visual basic 6 I've been spoilt with the code completion that had.

Don't get me wrong though, I really like code::blocks.

[takeshimiya]

This was like this forever. It's normal editor's behaviour.

In reallity, yes it has been like this forever, but it's a behavior/bug introduced in wxScintilla.
Scintilla works like royalbox descripted, which is less painful. Nothing to do in C::B anyways.

If you want to select a line, move your pointer over the line numbers.

I've sent a patch some weeks/months ago for correcting the problem (it was the most annoying thing for me, and I made it an option just in case), but I can't see what happened as I don't have access to SF tracker.

[TDragon]

I forgot to mention code completion which I think is still a long way from being very useful.

Maybe the devs should add Code Completion is a Work-In-Progress to the home page and the top of every forum page. Then people might actually realize that code completion is known not to work properly and the devs are aware of it.

[thomas]

Maybe the devs should add Code Completion is a Work-In-Progress to the home page and the top of every forum page.

Or maybe people should read.

It has been said many times (and there are at least two stickies on the forums) that the SVN version as a whole is work in progress and that people have to expect changes, bugs, and incomplete or missing features. The problem is that people don't listen to what you say.

[TDragon]

No kidding.

I was being facetious and more than a little sarcastic.

[yop]

If you want to select a line, move your pointer over the line numbers.

Another bunny out of the hat! This is a scintilla thingy? Really handy

[royalbox]

maybe people should read.

No kidding.

I was being facetious and more than a little sarcastic.

Gosh, the dodgy code completition is a real sore point for you chaps isn't it.

[sethjackson]

maybe people should read.

No kidding.

I was being facetious and more than a little sarcastic.

Gosh, the dodgy code completition is a real sore point for you chaps isn't it.

Nooo..... It is just that people do not read the forums too well. It seems there is a post about code-completion every day asking why this or that doesn't work. These types of questions have been asked and answered 1,000,000,000 times already. All you need to do is search the forum, and you will see that code-completion is a work in progress, and the devs know about 99.99999999% of the bugs that are in it/features "missing".

[royalbox]

@sethjackson
I tend to scim through the forum or search for a keyword I'm interested in before asking a question. On this occasion I was just making a comment about how I like code blocks except for what I see as the one major problem. It wasn't even a question.

Not to worry though, I'll steer well clear of posting next time.

[sethjackson]

@sethjackson
I tend to scim through the forum or search for a keyword I'm interested in before asking a question. On this occasion I was just making a comment about how I like code blocks except for what I see as the one major problem. It wasn't even a question.

Not to worry though, I'll steer well clear of posting next time.

I wan't talking about you..... I was saying why the devs get "touchy" about this topic. No offense to anyone was intended.

[royalbox]

@sethjackson
Sorry, my fault, the last sentence I made in the previous reply was a general comment.

[sethjackson]

@sethjackson
Sorry, my fault, the last sentence I made in the previous reply was a general comment.

Ok. 

[Zingam]

What does a "closed" bug fixed And do you sometimes close bugs when they are not fixed?

[Zingam]

maybe people should read.

No kidding.

I was being facetious and more than a little sarcastic.

Gosh, the dodgy code completition is a real sore point for you chaps isn't it.

Code completion is cool but I belive it should be added in version: 1.5 when all other more important things are done and when the whole IDE works properly as expected, even if some modern fancy features like code completion are missing.

I belive that CB shouldn't strive to become equal to VS with the first version but it should do all editing, project management, compiler support, GUI and all other basic features properly before starting to add more and more advanced features.

I have Visual Studio but for C++ programs I prefer Code::Blocks because it is small, it is fast and it runs under Linux too! If I want code completion so much I could use the monstrous VS and I hope CB never becomes as heavy weight as VS.
(It seems to me that MS always try to make the computers run as fast as at the time when they started on the original IBM PC - only their UI is prettier).

[royalbox]

The code::blocks versioning seems strange to me. I can't understand why it is called a 'release candidate' when it is still having new features added, bugs fixed and layout changed daily, and when one of it's features (code completion) is not anywhere near ready for release. I don't understand why they didn't stick to calling it a beta version until they had a version that they considered ready for release. Or, am I mistaken and the nightly builds are for the next version -- 1.1 or something? I can't see that as RC2 is miles behind the nightly builds. I don't understand the rush to get to 'version 1'. Other apps stay in beta for years until they're considered ready. What's wrong with that?

[Zingam]

Does it actually matter at all?

[thomas]

What does a "closed" bug fixed And do you sometimes close bugs when they are not fixed?

Yes, this happens, for example under the following conditions:
1. None of the devs is able to reproduce the bug throughout several releases. A few releases later, an inquiry whether the problem persists is made and there is no answer (or a negative answer).
2. The report misses significant detail and the developer examining the bug cannot reproduce it. An inquiry for more detail is made, but there is no answer.
3. The program behaves correctly, but the user does something wrong. The user is informed about this, and the report is eventually closed.
4. The user was correct, but the bug report was not processed for some reason, and in the meantime it has become obsolete because the bug was fixed by random chance (some other change). A note is made and the report is closed.
5. The user is being outright ignorant or stupid (or both). The bug it is not a bug at all, possibly the bug report is not even a bug report. The user is given a more or less polite answer (if it's me, then it may be less polite) and the report is closed.

The code::blocks versioning seems strange to me.

Yes, this has been discussed a couple of times in the past.
The problem with versioning is that we released the first RC too early. It only became clear after this that a few things would have to be greatly overhauled before you could call the IDE "usable".
However, once you go to RC, you cannot go back. If we started calling Code::Blocks "beta" again, it would lead to a lot more confusion (pre-RC beta vs. post-RC beta, old RC and new RC). Thus, we left it at that. It is not good, but it is the best we can do now.

[orefa]

A comprehensive and transparent answer worthy of sticky status.

[royalbox]

@thomas
Thanks for the answer, I understand what you're saying. It was unclear to me whether the 'final version 1" was going to be based on the current RC2 with bug fixes or the current work in progress. It's clear now.

Does it actually matter at all?

See my above answer if you genuinely want to know why I mentioned it.