Code::Blocks Forums
User forums => Nightly builds => Topic started by: killerbot on March 16, 2006, 11:05:26 pm
-
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 16 March 2006 build is out.
- Windows : http://download.berlios.de/codeblocks/CB_20060316_rev2202_win32.7z
- Linux : not supported yet
Resolved Fixed:
- CodeCompletion custom listcontrol
- closes on pressing SPACE Key,
- is positioned correctly on screen using dual monitor setup - Fixed setting of LD_LIBRARY_PATH to the current dir, for non-windows
ports, when running console applications - Disabled scripting for 64bit processors since AngelScript does not yet
support them - don't add to recent files when open (of not registered file types) in CB was cancelled (patch 930)
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)
-
Hello,
I have question about a really strange behavior with the nightly build.
I would like to know if it due to C::B or the Compiler
Here is a little (and useless) piece of code which reproduce my problem
#include <windows.h>
#include <stdio.h>
void test(char* str, char c) {
int i = 0;
if ((c == 0x22) || (c == 0x5c)) c += 1; // Avoid the characters ", \
str = c;
}
int main(void)
{
char s[10] = "123456789";
test(s, 'Z');
MessageBoxA(0, s, "Info", 0);
return 0;
}
Create a MS DOS project and paste the code above.
Launch it and you will see that the char* s will be equal to 123456789 instead of Z23456789 :shock:
Now remove the comment // Avoid the characters ", \ and it will work correctly
Is it a C::B bug or a Compiler bug?
-
It is neither, the code is wrong.
str = c; assigns the pointer, it does not write to it.
-
Besides, remove the line-continuation character '\' from the end of the comment...
This is not a bug report thread. Next time please use the appropriate board to post your "bugs"...
-
Besides, remove the line-continuation character '\' from the end of the comment...
Heh, did not even read that far :lol: But yes, that too.
-
Besides, remove the line-continuation character '\' from the end of the comment...
This is not a bug report thread. Next time please use the appropriate board to post your "bugs"...
OK, sorry.
But, what I do not understand is why the line below the comment is not taken in consideration while \ character it is contain in a comment
Concerning my piece of code I have made a mistake. The code I used was correct.
Thanks and have a nice day.
-
But, what I do not understand is why the line below the comment is not taken in consideration while \ character it is contain in a comment
That's for example explained here: http://www.gotw.ca/gotw/086.htm (except that in that example, a trigraph is used instead, which makes the matter even more confusing).
In one word, the statement str = c; is never evaluated because it is a comment.
-
Hi,
I noticed this kind of behavior in nightly build from 15 march (and 16 too):
when I edit my file and save changes, after about 1 second the editor stops responding for about 3-5 seconds. It's every time I save some changes.
By the way I have few quite big projects in C::B workspace and all of the files are on a network drive, so maybe this is the (indirect) cause of the problem. This lag wasn't present up to nightly build march 14th. I 'm using winxp version of C::B.
Regards
-
Whit all the nightly builds I have the same problem..
It looks like GNU GCC Compiler only takes notices of the the project options, and not to the build target options.
The policy is set to 'Append target options to project options', but it doesn't seem doing that..
The QT template project won't compile for that reason. (And all my excisting QT projects won't as well...)
Is this problem known?
Best regards,
Jaap
-
Whit all the nightly builds I have the same problem..
It looks like GNU GCC Compiler only takes notices of the the project options, and not to the build target options.
The policy is set to 'Append target options to project options', but it doesn't seem doing that..
The QT template project won't compile for that reason. (And all my excisting QT projects won't as well...)
Is this problem known?
Best regards,
Jaap
What steps do you take to build your Qt projects?
-
16 march release apparently crashes without any reason... i can't understand... it closes by itselfs without messages... I'm trying to find out the reason!
-
Whit all the nightly builds I have the same problem..
It looks like GNU GCC Compiler only takes notices of the the project options, and not to the build target options.
The policy is set to 'Append target options to project options', but it doesn't seem doing that..
The QT template project won't compile for that reason. (And all my excisting QT projects won't as well...)
Is this problem known?
Best regards,
Jaap
What steps do you take to build your Qt projects?
I found the problem.. It is not that cb won't append build target options. But cb doesn't recognize the $QTDIR variable (=c:\QT\...) wich is defined in the windows Environment Variables.