About few annoyances with RC2 (for some people)

[mandrav]

After a couple of annoyances/bugs with 1.0rc2 were discovered that affect few people, an update that addresses these will follow probably by the end of this week.

So, if you 've found one of these annoyances, please submit a bug-report at sourceforge about it. And please, do so as soon as possible.
Don't forget to set your bug-report's group to "1.0rc2". We 'll filter the reports for this group.
Or post here about it.

Only bug reports posted at sf.net, or in this very topic, will certainly be looked into.

On behalf of the Code::Blocks Team,
Yiannis.

[vserghi]

I've posted two bugs, but didn't see this message till after the fact. They do have RC2 in the header though.

Apologies, Vas.

[squizzz]

Not a bug, but I think it's good for a quick add:

- "save all" icon on toolbar
- accelerator key for switching to "Full Screen"

[rickg22]

Actually, I'm a little concerned, what's the roadmap? We haven't discussed this. What bugs should we fix before releasing it?

Also, at what point should we stop implementing *any* features (even minor, tiny ones) ?

[rickg22]

Go to the main codeblocks page, and on the left, there's a link which says: "report bug".

[orefa]

Also, at what point should we stop implementing *any* features (even minor, tiny ones) ?

Just my opinion: add NO new feature, the product is already quite good. Only fix known bugs then release this 1.0 version. There is an infinite amount of time to add features in new versions. Get one sturdy, official product out first, then build upon it.

[takeshimiya]

Yeah I think the same, spend more time bug-fixing the actual product and changing/revamping it, rather than adding functionality.

[MortenMacFly]

I just read a few things in the WiKi and found the article about the "personalities" feature. Very nice idea! However: When I startup RC2 with the --personality=ask (I also tried --personality="ask") parameter - as suggested in the WiKi - Code::Blocks crashes. Is it only me or is this an issue?!

Morten.

[mandrav]

I just read a few things in the WiKi and found the article about the "personalities" feature. Very nice idea! However: When I startup RC2 with the --personality=ask (I also tried --personality="ask") parameter - as suggested in the WiKi - Code::Blocks crashes. Is it only me or is this an issue?!

Morten.

Oops, it crashes indeed. From a quick glance, someone has added a debug message somewhere but it's too early to get hold of MessageManager (not initialised yet) and it crashes.
Thanks for pointing it out.

[mandrav]

OK, fixed in CVS.

[null]

I keep getting an error message when I start up CodeBlocks, after the splash window disappears but before the main window pops up. The message is 'The procedure entry point _ZN11TiXmlStringaSEPKc could not be located in the dynamic link library codeblocks.dll'. I kept the preferences from a previous installation (RC1-1) when I uninstalled it. Also, I had replaced some files from a CVS build overtop of the RC1-1 installation, so maybe an older version of something somehow managed to stick around. So this might not be a bug exactly, it might be my fault. Any ideas why I'm getting this error?

Also, CodeBlocks doesn't seem to remember my previous (most recent) workspace file. It keeps opening a much older one when it first starts. I might be misunderstanding the setting 'use default workspace'. (What defines 'default'?)

PS. C::B RC2 r0x0rz. Thanks so much for this wholesome opensource goodness! Soon... soon I will 'uninstall' the filth that is Visual Studio, and 'rm -rf' the horror that is KDevelop.

[MortenMacFly]

'The procedure entry point _ZN11TiXmlStringaSEPKc could not be located in the dynamic link library codeblocks.dll'

This error seems to origin from a wrong version/linking of the tinyxml library embedded in Code::Blocks. You seem to mix several versions of Code::Blocks DLL's (and therefore libraries) together. This cannot be good. I would strongly recommend a fresh re-install and the issues should be resolved.

I believe this is not a RC2 related issue.

Morten.

[null]

'The procedure entry point _ZN11TiXmlStringaSEPKc could not be located in the dynamic link library codeblocks.dll'

This error seems to origin from a wrong version/linking of the tinyxml library embedded in Code::Blocks. You seem to mix several versions of Code::Blocks DLL's (and therefore libraries) together. This cannot be good. I would strongly recommend a fresh re-install and the issues should be resolved.

I believe this is not a RC2 related issue.

Morten.

I suspected as much. I uninstalled again, and reinstalled again, and now everything seems to be working fine. Wierd how uninstalling the first time left old stuff behind.

[MortenMacFly]

I found out that for (static) libraries there is an issue if one uses custom variables for the output folder. This applies at least to the GCC compiler/archivar but maybe others are affected, too.

Steps to reproduce:
1.) Create a static library project (from the template)
2.) Set as output directory for the lib to: $(LIB_DIR_VAR)mylibname.a (note the missing folder separator)
3.) Build
Result: It works (so far!)
4.) Set the custom variable LIB_DIR_VAR to point to a directory, e.g. "D:\MyDir\" (note the trailing folder separator)
5.) Rebuild
Result: The "ar" command fails with:
ar.exe: libD:\MyDir\libmylibname.a: Invalid argument
As you can see the "lib" prefix is obviously added before (!) the environment variable is being translated.

It works, if one uses $(LIB_DIR_VAR)\mylibname.a and LIB_DIR_VAR points to "D:\MyDir" (note the added / removed folder separator).

However: it would work in both cases, if the LIB_DIR_VAR would first be translated and then the "lib" prefix added.

Why am I doing this the other way?

I wanted to have a specific output folder for the libraries in a cross-platform project (Windows and Linux). Thus by just replacing the variable I can set the output folder in the project and the libraries are being created wherever desired. Hence, if I choose the second variant (the working one) leaving out to set the LIB_DIR_VAR variable would leave as output: "/mylibname.a" which is unfortunately the root folder (!) on Linux - which is no good. What I wanted to have then is an output to the project folder which would be the case in the first variant because this leaves "mylibname.a".

I tried to explain as good as possible, hopefully (someone) will understand...  :lol:

Morten.

[MortenMacFly]

I found out that [...]

I filed this bug on sourceforge as well for better monitoring. One may ignore the message above... Sorry.

Morten.