The 21 march 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 21 March 2006 build is out.
  - Windows : http://download.berlios.de/codeblocks/CB_20060321_rev2220_win32.7z
  - Linux :
         http://download.berlios.de/codeblocks/CB_20060321_rev2220_ubuntu.deb
         http://download.berlios.de/codeblocks/CB_20060321_rev2220_fc4.rpm

Resolved Fixed:

• Patch #928 : Show/hide tabs in message pane - display the correct icons
• copystrings : reactivate pch and adjust unix cbp file

Regressions/Confirmed/Annoying/Common bugs:

• toolbar-images-not-changing-state (is a wx problem)
• there are several issues with Code Completion (is being redesigned : work in progress)

[Zingam]

Will this be permanent practice to release nightly builds for Linux too?


The linux version crashes quite often, the windows one almost never. How do I report these crashes?

[killerbot]

we will try to also provide the linux nightly, another one (rpm for suse) is also coming. I think we are at this time not able to provide them every night, but will do as much as possible. We like to guarantee it weekly and every higher frequency we can live up to we will provide ;-)

in linux there's also a CB crash report, post it, or just tell what has happened and if it can be reproduced and how it can be reproduced.

[skirby]

Hello,

I would like to reopen a bug (Bug #6791) on BerliOS site which was closed by mandrav whereas the problem still persists in the last nightly build (this one).
I am the author of that bug but I can neither reopen nor modify it.

What is the way to do this?

Thanks and have a nice day.

[mandrav]

Hello,

I would like to reopen a bug (Bug #6791) on BerliOS site which was closed by mandrav whereas the problem still persists in the last nightly build (this one).
I am the author of that bug but I can neither reopen nor modify it.

What is the way to do this?

Thanks and have a nice day.

There you go. Reopened. Let's see what more you have to add...

[Acki]

Hi,
I now have a problem with unknwn.h !!!
I'm using Irrlicht (3D graphics engine).
In Irrlicht a class is defined called IUnknown.
Now in C::B there is the same class defined !!!
This doesn't matter as long as I don't use the Irrlicht's namespaces !!!
But all my projects are using the namespaces of Irrlicht...
And Irrlicht uses 6 namespaces !!!
Now I have to walk though all the source codes, delete the using namespaces and add the namespaces to the classes (1000s of lines) !!!

So is there a chance that you change back the name of IUnknown, please ?!?!?

[mandrav]

So is there a chance that you change back the name of IUnknown, please ?!?!?

First, we don't have IUnknown anywhere in C::B sources.
Second, even if we did have IUnknown it wouldn't give you any problems with your projects.

The only IUnknown I know about, is from DirectX. So check your #includes and paths...

[thomas]

You are of course joking. You must be.

First of all, your statement is not true. There is no class IUnknown defined in Code::Blocks. You can easily verify this by doing a global search on the sources, the string IUnknown does not appear anywhere (not even in a contrib plugin or a resource file).

Second, what would it matter if Code::Blocks did define such a class? That is absolutely irrelevant for any of your projects (unless you copy and paste our code into your project).

Third, namespaces have the purpose of avoiding such conflicts, and they do so quite reliably if you use them correctly. Of course, if you use one or more large libraries (such as Irrlicht) and start every source file with using every_namespace_in_existence then you deserve the trouble you get from that. This is a well-known programming sin.

[Acki]

Well, I don't know where unknwn.h belongs to...
But there is a pragma declared in it: #pragma GCC system_header
And there is IClassFactory defined in it: #define __IClassFactory_INTERFACE_DEFINED__
That's why I thought it belongs to C::B ?!?!?
And sorry, IUnknown isn't a class, it's a typedef: typedef IUnknown *LPUNKNOWN;
The file unknwn.h is located within c:\CodeBlocks\include
The errors occur only if I use Irrlicht and include windows.h !!!
And I havn't had this error before...

[thomas]

The file unknwn.h is located within c:\CodeBlocks\include

As are about 600-800 other files. None of them is necessarily related to Code::Blocks.

And I havn't had this error before...

Have you used google before?

I found this within 10 seconds:
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_dec_2004/directx/DirectXSDK/reference/IUnknown/iunknown_interface.asp


What happens here is you include headers from Irrlicht and (a possibly non-authorative version of) DirectX and what not. In addition, you make all classes that are wisely hidden inside namespaces globally visible by using using globally.

[TDragon]

The only IUnknown I know about, is from DirectX. So check your #includes and paths...

He speaketh words of truth; yea, wisdom floweth from his lips as honey from the comb.

And sorry, IUnknown isn't a class, it's a typedef: typedef IUnknown *LPUNKNOWN;

Wrong; that's typedef-ing LPUNKNOWN to be of type IUnknown*. IUnknown is a global DirectX interface from which nearly all DirectX classes eventually inherit. IUnknown is also an Irrlicht interface (from the irr namespace) from which nearly all Irrlicht classes inherit. Conflicts occur when you import the irr namespace into the global namespace after including any header which directly exposes the DirectX IUnknown interface.

[Acki]

Well, but don't call me a fool !!!
But I havn't had this before the last C::B update !!!
So I'm sure it has to do with the last C::B update !!!
Right, it's always easier to point to other components...

[killerbot]

I am also rather sure it has nothing to do with CB, but could you tell with which version you now have this problem, and with which version you did not. (revision numbers please)


kind regards,
Lieven

[mandrav]

Well, but don't call me a fool !!!

Nobody called you a fool.

But I havn't had this before the last C::B update !!!

And stop shouting, please.

So I'm sure it has to do with the last C::B update !!!
Right, it's always easier to point to other components...

The "last C::B update" is very vague. You haven't even told us which version you 're using.
Besides, the folder codeblocks/include contains gcc system headers and is only available when installing the full RC2 setup. not C::B's headers...

So instead of shouting at us, why don't you learn something? Your problem has its solution and it has already been posted. Read this well:

Conflicts occur when you import the irr namespace into the global namespace after including any header which directly exposes the DirectX IUnknown interface.

Now, do yourself a favour and read it.
And then click this little "Add thank you" link above TDragon's post to acknowledge his help to you.

[MortenMacFly]

There you go. Reopened. Let's see what more you have to add...

Please also note: http://forums.next.codeblocks.org/index.php?topic=2582.0 because I believe it's related and more general.
With regards, Morten.