Code::Blocks

User forums => Nightly builds => Topic started by: killerbot on February 28, 2010, 09:19:34 am

Title: The 27 February 2010 build (6181) is out.
Post by: killerbot on February 28, 2010, 09:19:34 am
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works (http://forums.codeblocks.org/index.php/topic,3232.0.html).

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810_gcc441.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc441.7z

The 27 February 2010 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20100227_rev6181_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 27 February 2010 build (6181) is out.
Post by: killerbot on February 28, 2010, 09:20:30 am
IMPORTANT : everything is now build with the TDM-GCC 4.4.1 compiler.
It is advised to redownload also the mingwm dll and wx dll. Also these hve been rebuild with the new compiler.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: jens on February 28, 2010, 09:31:40 am
As usually debian binaries (32- and 64-bit), sources and documentation packages (german and english) can be found in my repository.

See here (http://apt.jenslody.de) how to use it.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: stefanos_ on February 28, 2010, 10:06:49 am
Good morning everyone.

So let me get this straight people: Those who still using the traditional MinGW they should migrate to TDM's GCC? And if so, what's the purpose or the difference? My apologies if I sound totally out of subject but all this time I was synchronizing my code with svn and compiling it using MinGW 5.1.6 (g++ 3.4.5 to be more precise).

Can someone please advice?

Cheers.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: jens on February 28, 2010, 10:56:40 am
Good morning everyone.

So let me get this straight people: Those who still using the traditional MinGW they should migrate to TDM's GCC? And if so, what's the purpose or the difference? My apologies if I sound totally out of subject but all this time I was synchronizing my code with svn and compiling it using MinGW 5.1.6 (g++ 3.4.5 to be more precise).

Can someone please advice?

Cheers.
If you compile C::B yourself, you can use the compiler you like, if it  is recent enough and works, it's okay.

If you use the newest nightly, you need http://prdownload.berlios.de/codeblocks/mingwm10_gcc441.7z (http://prdownload.berlios.de/codeblocks/mingwm10_gcc441.7z) and http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810_gcc441.7z (http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810_gcc441.7z), because they are build with (respectively part of) TDM's gcc 4.4.1 distribution.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: stefanos_ on February 28, 2010, 11:48:36 am
GNU / Linux Fedora is using the latest GNU CCC 4.4.1, which basically is the same (more or less) as TDM's GCC. I will keep my current specs as they are, and for experimental purposes I will cross-compile my latest svn code under GNU / Linux Fedora, not just for local usage but for Windows as well.

I think that will do. Correct me if I am wrong.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: ollydbg on March 01, 2010, 03:28:04 am
@killerbot

Which version of TDM GCC 4.4.1 did you use to build this nightly and wxWidgets library? DW2 or SJLJ ?
Thanks.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: pdsonic on March 01, 2010, 04:13:47 am
Thank you   thank you   thank you.    :D

Since I started using code blocks about 5 years ago, I have been for the virtual space feature. A feature I used in the Borland IDE. Now it is finally here.

Thanks guys for all your hard work!


Title: Re: The 27 February 2010 build (6181) is out.
Post by: nanyu on March 01, 2010, 06:11:35 am
Found a bug:

EDIt : 0. start c::b, and close all workspace. (and only "start here" page showing)
  (if a workspace been opening, everything ok.)

1. undock the Management window.
2. active the (undocked) Management window. (by click it's caption bar)
3. Press KEY : Ctrl + Tab
4. C::B (svn 6181, with wxmsw28u_gcc_cb_wx2810_gcc441) crash.

//////////////////////
windows xp  mingw32
Title: Re: The 27 February 2010 build (6181) is out.
Post by: nanyu on March 01, 2010, 06:19:17 am
Found another bug:

1. selected the new options : "Show close on all tabs"
2. closed the "Symbols" tab on "Management" by click the 'x' button.
3. press "Shift + F2"
4. c::b crash.

//////////////////////
windows xp  mingw32
Title: Re: The 27 February 2010 build (6181) is out.
Post by: shurecki on March 01, 2010, 06:51:04 am
I am having two problems
1. when there is a compilation error, the editor doesn't highlight the line with the error
2. if I spend sometime with CB open but without using it, when I start using it again CB freezes forever
Title: Re: The 27 February 2010 build (6181) is out.
Post by: killerbot on March 01, 2010, 07:50:11 am
@killerbot

Which version of TDM GCC 4.4.1 did you use to build this nightly and wxWidgets library? DW2 or SJLJ ?
Thanks.
should check, but I downloaded the 'all' installer and then stick with it's suggestions.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: killerbot on March 01, 2010, 07:51:11 am
@nanyu : could you report those 2 bugs in our bug tracker at berlios please.
Many thanks.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: ollydbg on March 01, 2010, 07:55:15 am
@killerbot

Which version of TDM GCC 4.4.1 did you use to build this nightly and wxWidgets library? DW2 or SJLJ ?
Thanks.
should check, but I downloaded the 'all' installer and then stick with it's suggestions.
Ok, that must be SJLJ version. I use this version too.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on March 01, 2010, 01:17:10 pm
Tab switcher by Ctrl+Tab sometimes works bad - it activates tab that differs from the selected item in the popup list (that is shown by Ctrl+Tab). I don't know why this happens - I can say only that it is not a systematic bug!
Title: Re: The 27 February 2010 build (6181) is out.
Post by: dirk_1980 on March 01, 2010, 02:13:29 pm
Geat job,
C::B is getting better from version to version but:

Under Environment settings - Thread search: alle Buttons are without text (std english).
And of course it is still impossible to write code with #ifdef #else #endif.

Dirk
Title: Re: The 27 February 2010 build (6181) is out.
Post by: afb on March 01, 2010, 04:09:23 pm
- Mac OS X 10.4 - 10.6: (32-bit Universal ppc/x86 with wxWidgets 2.8.10 + patch (http://wiki.wxwidgets.org/Development:_wxMac#Building_under_10.6_Snow_Leopard))
    http://prdownload.berlios.de/codeblocks/CB_20100227_rev6181_mac2810.zip

* Fixed the linking problems with wxSmithContribItems from the last Mac "nightly"
Title: Re: The 27 February 2010 build (6181) is out.
Post by: tretton on March 01, 2010, 04:47:47 pm
Thanks! Great work, as always!

Two things though:

1) Would it be possible to hide the horizontal scrollbar if all lines are short enough to fit? I like my editors as minimal as possible!

2) Tab characters in Abbreviations are inserted verbatim as tabs (\t), and do not seem to respect the "Use TAB character" setting under General settings. Is this intended?

Please point me in the right direction if this the wrong place to post about these things.

Thanks again!
-tretton
Title: Re: The 27 February 2010 build (6181) is out.
Post by: stahta01 on March 01, 2010, 10:29:25 pm
Thanks! Great work, as always!

Two things though:

1) Would it be possible to hide the horizontal scrollbar if all lines are short enough to fit? I like my editors as minimal as possible!

2) Tab characters in Abbreviations are inserted verbatim as tabs (\t), and do not seem to respect the "Use TAB character" setting under General settings. Is this intended?

Please point me in the right direction if this the wrong place to post about these things.

Thanks again!
-tretton

Bugs that are new in current nightly post here.

Feature request post
http://developer.berlios.de/account/login.php?return_to=%2Ffeature%2F%3Ffunc%3Daddfeature%26group_id%3D5358
Title: Re: The 27 February 2010 build (6181) is out.
Post by: Wavesonics on March 02, 2010, 12:41:37 am
Great job on this patch, some real nice things in here :D

I'm really glad someone finally got around to getting an SFML project template in there, but I'm having some problems with.

First, this is small, but when I worked on my template wizard for SFML i talked with Laurent (SFML's author), and he requested these 2 images be used, not a big deal, but at least on mine, the small icon has a strange black bar anyway:

Small Logo:
(http://www.grendelsdomain.com/~adam/images/sfml_wiz/logo.png)

Wizard Image:
(http://www.grendelsdomain.com/~adam/images/sfml_wiz/wizard.png)

And the second thing, is that the 3rd screen, where you need to locate SFML, I point it to the correct directory, but it can not detect "Audio.hpp". I've double and triple checked, it's the correct path, and the file is definitely there.

Anyway, glad to see things progressing, keep up the good work!
Title: Re: The 27 February 2010 build (6181) is out.
Post by: ikipiki on March 02, 2010, 01:25:25 pm
Thanks for this patch, I really like CD and I use it for many years. I really think you should make some final release, but it's up to you...

I would like to add just one suggestion. When I have a project with lot of dirs and subdirs for sources it is really hard to use notebook tabs because their contains relative path to the sources. I think that you could add option for turning off relative path showing in tabs so they can only show filenames.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on March 02, 2010, 01:33:45 pm
ikipiki: there is such option, you've not found it :)
Title: Re: The 27 February 2010 build (6181) is out.
Post by: ikipiki on March 02, 2010, 02:07:05 pm
 :o
i did now....
I was searching for it under environment options, i didnt realise its under editor options.
thanks
Title: Re: The 27 February 2010 build (6181) is out.
Post by: SharkCZ on March 02, 2010, 02:32:07 pm
For Fedora packages of C::B nigthly builds see my Fedora repo (http://fedora.danny.cz/danny), for RHEL/CentOS packages see my EL repo (http://fedora.danny.cz/danny-el) The official Fedora and EPEL packages (still 8.02) are waiting for a new release of C::B.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: pasgui on March 02, 2010, 03:33:10 pm
Build for Ubuntu i386/amd64 can be found here (http://lgp203.free.fr/ubuntu) (howto (http://lgp203.free.fr/spip/spip.php?article1))

wxWidgets for amd64:
- From Hardy Heron 8.04 to Jaunty Jacklope 9.04: wxWidgets from http://www.wxwidgets.org (http://www.wxwidgets.org) (howto (http://lgp203.free.fr/spip/spip.php?article1))
- For Karmic Koala 9.10: wxWidgets from http://www.wxwidgets.org (http://www.wxwidgets.org) with jaunty-wx for the distribution (howto (http://lgp203.free.fr/spip/spip.php?article1))
wxWidgets for i386:
- From Hardy Heron 8.04 to Jaunty Jacklope 9.04: wxWidgets from http://www.wxwidgets.org (http://www.wxwidgets.org) (howto (http://lgp203.free.fr/spip/spip.php?article1))
- For Karmic Koala 9.10: wxWidgets from Ubuntu (universe)

Also included in the codeblocks-fr package (in the same repository), the french translation.

Best regards, pasgui
Title: Re: The 27 February 2010 build (6181) is out.
Post by: tretton on March 03, 2010, 09:36:43 am
All right, thanks stahta01!

Then I'd like to post this here as a potential bug: Tabs in Abbreviations do not seem to respect the "Use TAB character" setting under General settings, but instead always use tabs. This behaviour is present in many, if not all, versions.

Thanks again!
Title: Re: The 27 February 2010 build (6181) is out.
Post by: stahta01 on March 03, 2010, 04:03:54 pm
All right, thanks stahta01!

Then I'd like to post this here as a potential bug: Tabs in Abbreviations do not seem to respect the "Use TAB character" setting under General settings, but instead always use tabs. This behaviour is present in many, if not all, versions.

Thanks again!

Please read

http://wiki.codeblocks.org/index.php?title=Main_Page
Title: Re: The 27 February 2010 build (6181) is out.
Post by: tretton on March 03, 2010, 05:18:58 pm
Sorry to be a pain, but do you mean a particular page or simply the entire wiki? I tried searching for "abbreviations", but that didn't yield much.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: stahta01 on March 03, 2010, 06:32:46 pm
Sorry to be a pain, but do you mean a particular page or simply the entire wiki? I tried searching for "abbreviations", but that didn't yield much.

Read ALL of that PAGE it has the places to submit feature requests and bugs.

Tim S.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: tretton on March 03, 2010, 06:37:50 pm
Oh, I thought you meant that I should post bugs in this thread, and feature requests on BerliOS. My bad, then!

EDIT: bugs/features posted to BerliOS!
Title: Re: The 27 February 2010 build (6181) is out.
Post by: elettronica67 on March 03, 2010, 08:16:08 pm
Hi, thank you for your job
on the windows distribution I have found some icons missing.
I have copied the icon folders from the previous nightly-build (6088) and all seems to work fine.

The missingo folders are:
share\CodeBlocks\images\codesnippets
share\CodeBlocks\images\ThreadSearch
share\CodeBlocks\images\wxsmith

On Ubuntu all works fine!!

Thanks again
Paolo
Title: Re: The 27 February 2010 build (6181) is out.
Post by: stefanos_ on March 03, 2010, 10:00:29 pm
Current svn version 6182 just crashed while had all Code::Blocks's wxs open for GUI comprehesion, and decided to close workspace. Upon closing it crashed and an RPT file was created.

Here is the crash report: http://pastebin.ca/1821790

System specs:


I have tried to reproduce the same bug but unfortunately I couldn't.

Thank you very much.

Regards,

Stefanos
Title: Re: The 27 February 2010 build (6181) is out.
Post by: wavelet on March 04, 2010, 01:56:16 am
good job  :D
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on March 04, 2010, 05:51:18 am
Problem with automatic insertion of double quotes (") - in '(' and ')' I place autogenerated double quote:

Code: [Select]
"(") // it's ok
"(")some_code // double quote mustn't be generated before some_code if there is no space between them
some_code"(") // double quote mustn't be generated after some_code if there is no space between them

I like this feature, but the above behaviour is noisy - I need to delete autogenerated double quote.

Did you notice this: http://forums.codeblocks.org/index.php/topic,11875.msg81723.html#msg81723 about autogeneration of scopes ({})?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: blueshake on March 05, 2010, 08:26:54 am
Problem with automatic insertion of double quotes (") - in '(' and ')' I place autogenerated double quote:

Code: [Select]
"(") // it's ok
"(")some_code // double quote mustn't be generated before some_code if there is no space between them
some_code"(") // double quote mustn't be generated after some_code if there is no space between them

I like this feature, but the above behaviour is noisy - I need to delete autogenerated double quote.

Did you notice this: http://forums.codeblocks.org/index.php/topic,11875.msg81723.html#msg81723 about autogeneration of scopes ({})?

@critic

sorry to say I failed to make a patch for this.Today I spend time on it and find it is diffcult to do this.I am not statisfied with the reuslt. :(if you want to do this.you can learn something from eranif's codelite, in the file cl_editor.cpp.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: Lord Delvin on March 05, 2010, 10:01:09 am
Is it possible to change behavior of f11(switching between header/source) To switch to the source/header in the same namespace/directory? In any version tested, that should be all nightlies in the last 3 months, f11 seems to switch to some sort of "default" header.

As allways: I love what you do:)

EDIT: @Xaviou/pasgui: Is there a reason why theres no current amd64 build in the lpg repo?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: ollydbg on March 05, 2010, 10:13:51 am
Is it possible to change behavior of f11(switching between header/source) To switch to the source/header in the same namespace/directory? In any version tested, that should be all nightlies in the last 3 months, f11 seems to switch to some sort of "default" header.

As allways: I love what you do:)

EDIT: @Xaviou/pasgui: Is there a reason why theres no current amd64 build in the lpg repo?
If I can remember, we have discussed this several months ago, and morten has done some thing in the CC's code. I think the defaualt way is switch the files in the same folder. Can you give me a specific example? Also, we have a CC's testing workspace in the SVN source, can you test it?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on March 05, 2010, 10:45:18 am
Olly: this has nothing to do with CC
Lord Delvin: there was a discussion but I think no one implemented the proposed solution (corrections to this statement are welcome)
Title: Re: The 27 February 2010 build (6181) is out.
Post by: Lord Delvin on March 05, 2010, 11:58:18 am
Theres an easy and fast way to reproduce what i mean:

Create an empty project.
Create new Class -> n1::Test
Create new Class -> n2::Test

goto one ef n2::Test's files and press F11.

I never wanted to mess with your code, but maybe i will get the svn and try to fix that.

EDIT: Im unable to build Codeblocks (6181 and current, that was 6187 i think). Build and install works fine, but codeblocks refuses to start with error:
"codeblocks: symbol lookup error: codeblocks: undefined symbol: _ZTI17wxScrollingDialog"
(I'm using wx-dev packages version 2.8.10 from wx repository)

@ollydbg: I dont CC can create this bug, but i never looked at CB's code.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: pasgui on March 05, 2010, 10:46:44 pm
EDIT: @Xaviou/pasgui: Is there a reason why theres no current amd64 build in the lpg repo?

In fact, I can build only i386 and Xaviou provides the amd64 builds.

best regards, pasgui
Title: Re: The 27 February 2010 build (6181) is out.
Post by: Kazade on March 06, 2010, 10:25:05 am
I don't suppose anyone is building AMD64 packages for Lucid yet? I've tried the ones from both Pasgui's and Jens' repositories both are incompatible with the wxwidgets in Lucid:

Code: [Select]
codeblocks: relocation error: /usr/lib/libcodeblocks.so.0: symbol _Z18wxSafeConvertWX2MBPKw, version WXU_2.8.2 not defined in file libwx_baseu-2.8.so.0 with link time reference
Title: Re: The 27 February 2010 build (6181) is out.
Post by: pasgui on March 06, 2010, 12:16:26 pm
I don't suppose anyone is building AMD64 packages for Lucid yet? I've tried the ones from both Pasgui's and Jens' repositories both are incompatible with the wxwidgets in Lucid:

Code: [Select]
codeblocks: relocation error: /usr/lib/libcodeblocks.so.0: symbol _Z18wxSafeConvertWX2MBPKw, version WXU_2.8.2 not defined in file libwx_baseu-2.8.so.0 with link time reference

Try to install wxWidgets from wxWidgets.org: jaunty-wx instead of packages from lucid

Best regards, pasgui
Title: Re: The 27 February 2010 build (6181) is out.
Post by: Kazade on March 07, 2010, 09:31:15 am
I don't suppose anyone is building AMD64 packages for Lucid yet? I've tried the ones from both Pasgui's and Jens' repositories both are incompatible with the wxwidgets in Lucid:

Code: [Select]
codeblocks: relocation error: /usr/lib/libcodeblocks.so.0: symbol _Z18wxSafeConvertWX2MBPKw, version WXU_2.8.2 not defined in file libwx_baseu-2.8.so.0 with link time reference

Try to install wxWidgets from wxWidgets.org: jaunty-wx instead of packages from lucid

Best regards, pasgui

Thanks pasgui, but I tried that. The version in Lucid supersedes the one in the repository, I could force the version but I don't want to break anything else.

For now I've self-compiled Code::Blocks which is working fine :)
Title: Re: The 27 February 2010 build (6181) is out.
Post by: MortenMacFly on March 10, 2010, 07:07:55 am
To make it short... Please notice:
http://forums.codeblocks.org/index.php/topic,12156.msg82577.html#msg82577
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on March 11, 2010, 12:12:24 pm
I made C::B plugin to build Qt projects (QtHelper). If you taste it you will see that it duplicates a lot of codeblocks' project settings widgets and forms. It is because of that this plugin generates makefile from C::B's project and then compiler uses this makefile for build and to work with C::B's project (configure it) I must duplicate these setting widgets because in projects those use custom makefile these options are disabled.

Somebody on this forum adviced me to do so (to duplicate), but the more I use C::B the more widgets I need to duplicate - it's not good - I copy you work.

May be it will be better to allow not only `custom makefile projects`, but simply `makefile projects`, i.e. projects those building goes through makrfile generation?

Please, answer me.
With regards, Mihail.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: MortenMacFly on March 11, 2010, 03:45:11 pm
i.e. projects those building goes through makrfile generation?
The problem here is: We cannot do a lot of things using Makefiles, they are just too limited. Take scripting in pre- and post-build steps for example. So a Makefile generation will always be only a sub-set of what's actually possible.

However, I see the chance for a more generic Makefile generator plugin (one exists already, but unsupported btw) to which other plugins (like a qt plugin) could contribute. I think that's the way to go... IMHO...
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on March 11, 2010, 03:48:39 pm
However, I see the chance for a more generic Makefile generator plugin (one exists already, but unsupported btw) to which other plugins (like a qt plugin) could contribute. I think that's the way to go... IMHO...
The way to go is a BuildSystemConverterPlugin + subplugins or something like that:)
But, I don't have inspiration to do it:)
Title: Re: The 27 February 2010 build (6181) is out.
Post by: galenchang on March 12, 2010, 02:42:59 am
Hello,

I don't know if this is the suitable place to post a bug report, but I've found that svn 6181 will crash when I drag the compiler toolbar off it's original position. I'm using windows 7. When I dragged the toolbar toward the bottom of the screen, the window became white and the cursor became busy style. After a while windows say the program must be terminated.

Notice the direction is to down to bottom, when I dragged it to the right, everything is OK.

I gave the report file generated by CB here. Hope someone would find the cause and fix it.

Thanks.

[attachment deleted by admin]
Title: Re: The 27 February 2010 build (6181) is out.
Post by: nanyu on March 12, 2010, 03:10:46 am
Hello,

I don't know if this is the suitable place to post a bug report, but I've found that svn 6181 will crash when I drag the compiler toolbar off it's original position. I'm using windows 7. When I dragged the toolbar toward the bottom of the screen, the window became white and the cursor became busy style. After a while windows say the program must be terminated.

Notice the direction is to down to bottom, when I dragged it to the right, everything is OK.

I gave the report file generated by CB here. Hope someone would find the cause and fix it.

Thanks.

pls update the wxmsw28u_gcc_cb.dll ... files... see : http://forums.codeblocks.org/index.php/topic,3232.0.html
Title: Re: The 27 February 2010 build (6181) is out.
Post by: galenchang on March 12, 2010, 06:01:50 am
....
pls update the wxmsw28u_gcc_cb.dll ... files... see : http://forums.codeblocks.org/index.php/topic,3232.0.html

Hi,

I'm using the latest version of wxmsw28u_gcc_cb.dll, downloaded from the links of first post of this thread. The version number is 2.8.10.0 from the file property dialog.  And the 7z package name is "wxmsw28u_gcc_cb_wx2810_gcc441.7z".

So I still think there is a potential bug hide.

Thanks.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: killerbot on March 12, 2010, 08:08:53 am
no no, that is correct. Because this is a new build with a different compiler ot the same sources, the dll could keep it's name, put the distribution package of it (the zip) got a new name to make sure which one it is.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: yanqingan on March 15, 2010, 09:25:02 am
Thank you ,I like this very much
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on March 15, 2010, 02:45:37 pm
In my plugin I catch cbEVT_COMPILER_STARTED event. When I build single project - all works fine, but when I choose Build workspace - only one project is built. I checked this and found that cbEVT_COMPILER_STARTED sended only one time for active project in workspace. But to build all workspace projects (Qt projects, for example) I need do it by activating and building them by hands - not good :(
May be it's a bug?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on March 16, 2010, 05:50:52 am
It seems I found the problem - it's in methods where DoPrepareQueue method is called

For example (compilergcc.cpp, line 2714)
Code: [Select]
int CompilerGCC::DoBuild(const wxString& target, bool clean, bool build, bool clearLog)
{
    wxString realTarget = target;
    if (realTarget.IsEmpty())
        realTarget = GetTargetString();

    if (!StopRunningDebugger())
        return -1;

    if (!CheckProject())
    {
        // no active project
        if (Manager::Get()->GetEditorManager()->GetActiveEditor())
            return CompileFile(Manager::Get()->GetEditorManager()->GetActiveEditor()->GetFilename());
        return -1;
    }

    if (realTarget.IsEmpty())
        return -1;

    if (!m_IsWorkspaceOperation)
    {
        DoClearErrors();
        InitBuildLog(false);
//    if (!m_IsWorkspaceOperation)
        DoPrepareQueue(clearLog);
    }

    PreprocessJob(m_Project, realTarget);
    if (m_BuildJobTargetsList.empty())
    {
        return -1;
    }
    InitBuildState(bjProject, realTarget);
    if (DoBuild(clean, build))
    {
        return -2;
    }
    return DoRunQueue();
}

and

Code: [Select]
void CompilerGCC::DoPrepareQueue(bool clearLog)
{
    if (m_CommandQueue.GetCount() == 0)
    {
        CodeBlocksEvent evt(cbEVT_COMPILER_STARTED, 0, m_Project, 0, this);
        Manager::Get()->ProcessEvent(evt);

        if(clearLog)
            ClearLog();
        DoClearErrors();
        // wxStartTimer();
        m_StartTimer = wxGetLocalTimeMillis();
    }
    Manager::Yield();
}

cbEVT_COMPILER_STARTED is sended from DoPrepareQueue method, but the latter is not called for workspace operations.

I don't know, maybe there is another way to do makefile generation in my plugin?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on March 16, 2010, 05:59:57 am
Else I found that building of referenced projects for some project is also don't work correctly - I think this is related to my previous post
Title: Re: The 27 February 2010 build (6181) is out.
Post by: skirby on March 17, 2010, 03:04:52 pm
Hello,

I have found strange bugs when installing Code::Blocks in virtual machine (Windows XP and Virtual Box v3.1.4)
The way to reproduce it is very easy.
Simply install Code:Blocks from the beginning.
- First, install codeblocks-8.02mingw-setup.exe (with standard or full install)
- Now, apply the last Nightly Build with : CB_20100227_rev6181_win32.7z, mingwm10_gcc441.7z and wxmsw28u_gcc_cb_wx2810_gcc441.7z
- Launch Code::Blocks => you get an error message (see screenshot)

(http://img197.imageshack.us/img197/8886/errorth.jpg) (http://img197.imageshack.us/i/errorth.jpg/)

The problem does not exists if I launch Code::Blocks directly after having installed codeblocks-8.02mingw-setup.exe (without nightly build)

The problem comes from the file startup.script which is corrupted. Just after the following line :
GetScriptingManager().RegisterScriptMenu(_("&Settings") + _T("/-") + _("Edit startup script"), _T("edit_startup_script.script"), false);
In line 18, you will find this:
alse);

And more, Code::Blocks crash when clicking in menu "Settings" and "Compiler and debugger"
(See codeblocks.RPT in attachment for more information)

These "bugs" do not exist when installing Code::Blocks normally (not in virtual machine)

Can you confirm this behavior?

Thanks and have a nice day.

[attachment deleted by admin]
Title: Re: The 27 February 2010 build (6181) is out.
Post by: stefanos_ on March 17, 2010, 05:03:13 pm
You should not mix nightly builds with stable editions. Please read the link below:

http://forums.codeblocks.org/index.php/topic,3232.0.html

Regards,

stefanos_
Title: Re: The 27 February 2010 build (6181) is out.
Post by: franzl on March 20, 2010, 12:48:15 pm
When I create a new project with the current nightly on Linux with the Intel C++ Compiler the default compiler settings are not correct. Codeblocks uses the windows compiler settings, but they differ from those which are needed under Linux.

http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/index.htm (http://software.intel.com/sites/products/documentation/hpc/compilerpro/en-us/cpp/lin/compiler_c/index.htm)

Creating a C/C++ project the defaults are:
- general: /EHs (enable synchronous C++ exception handling model)
- Debug: /Zi (generate full debugging information in the object file)
- Release: /O2 (enable optimizations for speed)

Correct ones would be:
- general: (not existing under Linux)
- Debug: -g
- Release: -O2

kind regards
Franzl
Title: Re: The 27 February 2010 build (6181) is out.
Post by: Jan van den Borst on March 22, 2010, 12:04:20 pm
Hi All,
I'm using an custom compiler Keil Arm.

I constantly experiencing crashes in the projectfileoptionsdlg when unchecking the link and compile checkbox.
I traced down the error to line 402 of the projectfileoptionsdlg.cpp file. Checking the compiler fixes the error but probably is not what you want:

void ProjectFileOptionsDlg::SaveBuildCommandSelection()
{
    Compiler* compiler = CompilerFactory::GetCompiler(m_LastBuildStageCompilerSel);
    if(compiler)
    {
      m_ProjectFile->customBuild[compiler->GetID()].useCustomBuildCommand = XRCCTRL(*this, "chkBuildStage", wxCheckBox)->GetValue();
      m_ProjectFile->customBuild[compiler->GetID()].buildCommand          = XRCCTRL(*this, "txtBuildStage", wxTextCtrl)->GetValue();
    }
}

Regards
Jan
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 01, 2010, 06:49:40 am
Can you add to C::B:
Code: [Select]
class Name
{

};// here
Code: [Select]
In source formatter settings there is option `Indent classes (keywords public:, protected: and private:)`

As I see source formatter doesn't work for me (other options don't work too) and I don't know why (plugin is enabled and configured).
Have you any comments about this?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 05, 2010, 12:08:54 pm
Now I use C::B and I have a lof of files opened. Drop down list in the upper-right side of editor is not sorted and it's very difficult to search file in it. I think it must be sorted.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: killerbot on April 05, 2010, 01:37:45 pm
Now I use C::B and I have a lof of files opened. Drop down list in the upper-right side of editor is not sorted and it's very difficult to search file in it. I think it must be sorted.
that makes sense, could you file a request (or event a bug) for it on our berlios page so this doesn't get lost.

EDIT : note to CB developers, I have no idea how it was back in our previous release, but if back then it was sorted, we should sort it back before a new release.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: jens on April 05, 2010, 10:23:21 pm
Now I use C::B and I have a lof of files opened. Drop down list in the upper-right side of editor is not sorted and it's very difficult to search file in it. I think it must be sorted.
that makes sense, could you file a request (or event a bug) for it on our berlios page so this doesn't get lost.

EDIT : note to CB developers, I have no idea how it was back in our previous release, but if back then it was sorted, we should sort it back before a new release.
I suggest using the open files list plugin ("View -> Open files list"), it uses a sorted list.

EDIT:
I just tested the 8.02 behaviour and it also shows the dropdownlist in the same order the tabs are displayed.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: GaoHan on April 06, 2010, 04:07:24 am
Hello all,

First of all thank you for the fantastic program! Took me a while, but got it now all set up with CMake as makefile generator, but it works like a charm now!

Secondly, I am not sure if it is a bug or something, but sometimes when I would open a new dialog, for example for making a new project, the dialog is sometimes not shown in front but behind the main screen (at least I assume that, because i always run CB fullscreen). As a result the main window locks up, and there is no way to get the dialog to the front. No matter where I click in the screen, I will hear the Windows Plung sound. The only thing i can do in such a moment is to kill the process by the task-manager. I have lost quite some data in this way, but I need to use the SVN build for the prebuild steps needed with CMake.

Any advice is appreciated!

Gao Han

PS: I am running C::B build 6181 on Windows 7 x64 together with GNU GCC.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 07, 2010, 05:10:52 pm
Hi! Nice to hear that there will be a new release.

"svn build rev 6202 (2010-04-06 05:38:22) gcc 4.3.4 Linux/unicode - 32 bit" pops up a message on startup which I can't read because it's white-on-yellow. The color scheme is hard-coded to use black text in some places (like output tabs) which makes the text unreadable in sensible (i. e. bright-on-dark) system color schemes.

Another bug: Scrolling the editor with the mouse wheel doesn't work properly. If I scroll the wheel *very* slowly, the GUI reacts to every wheel movement by scrolling the editor text up and down; but if I scroll faster, most mouse wheel events seem to be lost, and the editor text hardly scrolls at all.



Hmmm. I recompiled & installed both wxWidgets 2.8.10 and Code::Blocks, and now Code::Blocks crashes on startup. Does anybody know why that happens? ... I'm attaching the debug report.

[attachment deleted by admin]

[attachment deleted by admin]
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 07, 2010, 05:35:40 pm
foobar123: can you test http://developer.berlios.de/patch/?func=detailpatch&patch_id=2855&group_id=5358 to see if it fixes the dark theme problems?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 07, 2010, 08:30:26 pm
I would test the patch if I could get any version to start. The following happens with the latest SVN tip and with revision 6181, too - this output is from 6181:
Code: [Select]
codeblocks
Initialize EditColourSet .....
Initialize EditColourSet: done.
Loading toolbar...
Debugger: loaded
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxFileDialog32.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxFileDialog16.png': file does not exist.
08:08:57 PM: Error: Can't load image from file [...]
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxButton32.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxButton16.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxGridSizer32.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxGridSizer16.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxHtmlWindow32.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxHtmlWindow16.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxStaticLine32.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxStaticLine16.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxScrolledWindow32.png': file does not exist.
08:08:57 PM: Error: Can't load image from file '�����������������������������������������������������������)����������������������������������)�����������������/images/wxsmith/wxScrolledWindow16.png': file does not exist.
Aborted (core dumped)

Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 07, 2010, 09:43:08 pm
OK, so I figured out that if I remove any package with "codeblocks" and "wx" in the name, then re-install both the wxGtk 2.8.10 and Code::Blocks from source, the above error goes away. Once I reinstall a wxGtk package, problem reappears. So apparently its a subtle incompatibility between recent Code::Blocks code and the wxGtk packages that's causing the error.

Unfortunately other apps depend on the wxGtk packages, so I now have the choice of running either recent Code::Blocks, or *any* other app that uses wxGtk.

:-(
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 07, 2010, 09:46:02 pm
OS? You should link C::B use the same library files (.so-s) for the building and running C::B, else strange things can happen.

Why not install wxGTK-dev?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 07, 2010, 10:06:17 pm
Why not install wxGTK-dev?

Because wxgtk-dev depends on the package which makes Code::Blocks crash, like I explained above.

I'm using Ubuntu 9.10.

I also tried the apt line Jens recommends at http://apt.jenslody.de/ , but the packages from that repository are incompatible too.

When I install both the wxGtk I compiled from source and the packaged versions, Code::Blocks crashes too - it seems to prefer the packaged, incompatible version.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: jens on April 07, 2010, 10:11:23 pm
Why not install wxGTK-dev?

Because wxgtk-dev depends on the package which makes Code::Blocks crash, like I explained above.

I'm using Ubuntu 9.10.

I also tried the apt line Jens recommends at http://apt.jenslody.de/ , but the packages from that repository are incompatible too.

When I install both the wxGtk I compiled from source and the packaged versions, Code::Blocks crashes too - it seems to prefer the packaged, incompatible version.

Did you read this note:
Quote from: http://apt.jenslody.de/
If you want to use my packages on ubuntu 9.10 (karmic koala) you have to use the packages provided by http://apt.wxwidgets.org  for jaunty, because the wx2.8.10 packages from ubuntu are not compatible with the packages from http://apt.wxwidgets.org.
There exists also a repository containing packages for ubuntu, maintained by pasgui, see here (http://lgp203.free.fr/spip/spip.php?article1) how to use it.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 07, 2010, 11:39:58 pm
Did you read this note:
Quote from: http://apt.jenslody.de/
If you want to use my packages on ubuntu 9.10 (karmic koala) you have to use the packages provided by http://apt.wxwidgets.org  for jaunty, because the wx2.8.10 packages from ubuntu are not compatible with the packages from http://apt.wxwidgets.org.
There exists also a repository containing packages for ubuntu, maintained by pasgui, see here (http://lgp203.free.fr/spip/spip.php?article1) how to use it.

The mentioned Ubuntu repository gives me the 8.02 code, not the code for the nightly build; and the source for the nightly build which I pulled from SVN doesn't build against the wxgtk-dev packages from the Ubuntu repository. First error is
Code: [Select]
In file included from ../../../src/include/sdk_precomp.h:13,
                 from tinywxuni.cpp:1:
../../../src/include/sdk_common.h:34:23: error: wx/wxprec.h: No such file or directory
I installed the dev packages as recommended with "sudo apt-get install libwxgtk2.8-0 libwxgtk2.8-dev wx2.8-headers wx-common".

I'm now trying to build against the wxgtk2.8.10 which I installed from source, while keeping the wxgtk packages from pasgui's Ubuntu repositories installed, so that I can run other wxgtk apps.

Edit: Well, no; that didn't work out. Code::Blocks SVN rev. 6181 + wxgtk source + wxgtk packages from pasgui's Ubuntu repos still crashes.
I have to use other wx apps, so it's not possible to test any patch. Sorry.

Update: Finally. It's running!!!
Don't ask me what exactly I did, but I must have hit the right package combination somehow. Wow. :)

Update: The patch from http://developer.berlios.de/patch/?func=detailpatch&patch_id=2855&group_id=5358 fixes the white-on-yellow Warning text (but not the hardcoded-to-black Build messages text).  Please apply this patch.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 08, 2010, 01:01:23 am
... (but not the hardcoded-to-black Build messages text).  ...
Can you show me a screenshot?

edit: also the name of the theme you're using
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 08, 2010, 01:28:53 am
Sure.  Here's a screenshot with the Xfce-dusk theme. I usually hand-tweak the colors a bit with Gnome Color Chooser (I think it's *too* dark), but this is the plain unmodified theme.

While I'm at it =) The forum entry boxes also have the dark-on-dark problem. Same thing, probably: Foreground is set to black, but background color is left at the default, so when the default is dark, it's unreadable.

[attachment deleted by admin]
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 08, 2010, 11:09:29 am
Oh, I've once tried to fix this but failed... it is added to my TODO for another try...
Title: Re: The 27 February 2010 build (6181) is out.
Post by: GaoHan on April 08, 2010, 02:21:20 pm
Small point:

If on the last empty line of a file you type the accolade, it does not add the closing accolade.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 08, 2010, 02:27:38 pm
Oh, I've once tried to fix this but failed... it is added to my TODO for another try...

You mean the black text in output tabs? Well, in other places, like the status line, it's done correctly, like seen in the screenshot: The text uses the default foreground color.
To fix the output tabs, one would have to do whatever is done in the status line code to get the default text color.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: jens on April 08, 2010, 02:28:15 pm
Small point:

If on the last empty line of a file you type the accolade, it does not add the closing accolade.
I'm not sure what you mena with accolade, but I gues you have aproblem with auto-completion of braces and quotes ( "('[{}]')" ).

This issue is already fixed in trunk and will not appear in the next release.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: GaoHan on April 08, 2010, 02:33:15 pm
Oh, sorry, I guess it's just the dutch word for it... :) Accolade is the curly bracket thingy. Thank you for fixing!

Gao Han
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 08, 2010, 02:35:21 pm
You mean the black text in output tabs? Well, in other places, like the status line, it's done correctly, like seen in the screenshot: The text uses the default foreground color.
To fix the output tabs, one would have to do whatever is done in the status line code to get the default text color.
The matter is that the error lines are red, warning lines are blue and these two colors doesn't work well on black background...
Thought you're right that the normal text color should (and can easily) be fixed.

mods: can you move the post related to dark skins in another thread?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 08, 2010, 04:06:04 pm
The matter is that the error lines are red, warning lines are blue and these two colors doesn't work well on black background...
Thought you're right that the normal text color should (and can easily) be fixed.

Yes, dark blue doesn't work well on dark backgrounds either, but at least it's readable. Doing this whole thing correctly would involve either making the error and warning message color configurable, or composing the colors from a mixture of the default text foreground color and the desired color. I imagine mixing 25% default text color + 75% desired color would work well.

Quote
mods: can you move the post related to dark skins in another thread?

I thought this was the right thread for discussing bugs which should be fixed before the next release. Outputting text which can't be read is a bug.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 08, 2010, 07:06:17 pm
Yes, dark blue doesn't work well on dark backgrounds either, but at least it's readable. Doing this whole thing correctly would involve either making the error and warning message color configurable, or composing the colors from a mixture of the default text foreground color and the desired color. I imagine mixing 25% default text color + 75% desired color would work well.
Have you used the 25% + 75% scheme somewhere?

I thought this was the right thread for discussing bugs which should be fixed before the next release. Outputting text which can't be read is a bug.
I think no, there is Preparing for Release thread. Also this is not a regression, but normal bug.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 09, 2010, 03:39:34 pm
Have you used the 25% + 75% scheme somewhere?

No, it's an "educated guess" kind of thing. It might not look pretty with all color schemes but it would make the text more readable than it is now.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 09, 2010, 07:49:06 pm
Text colours again.

I've created a patch which applies to current svn head. This includes [ Patch #2855 ] Dark theme fixes (http://developer.berlios.de/patch/?func=detailpatch&patch_id=2855&group_id=5358) and also fixes the default colors for loggers like the search results. If the colour scheme is a bright-on-dark one, it also brightens the warning and error messages in the build messages, which makes them more readable (see screenshot).

I still haven't figured out how to set the colour of the notebook tabs properly - I can't find the place where the black text colour is hardcoded. This might even be in the wx libraries.

I hope this patch will be applied before the next release!

[attachment deleted by admin]
Title: Re: The 27 February 2010 build (6181) is out.
Post by: jens on April 09, 2010, 11:22:26 pm
I still haven't figured out how to set the colour of the notebook tabs properly - I can't find the place where the black text colour is hardcoded. This might even be in the wx libraries.

You can try this one, at least for C::B's own styles (MSVC anf FF2):
Code: [Select]
--- tmp/tmpq4jmq6-meld/notebookstyles.cpp
+++ home/jens/codeblocks-build/codeblocks.trunk/src/src/notebookstyles.cpp
@@ -155,6 +155,7 @@
         dc.SetFont(m_normal_font);
     dc.GetTextExtent(caption, &textx, &texty);
     // draw tab text
+    dc.SetTextForeground(wxSystemSettings::GetColour(wxSYS_COLOUR_CAPTIONTEXT));
     dc.DrawText(page.caption, text_offset,
                 drawn_tab_yoff + drawn_tab_height / 2 - texty / 2 - 1);
 
@@ -323,6 +324,7 @@
         dc.SetFont(m_normal_font);
     dc.GetTextExtent(caption, &textx, &texty);
     // draw tab text
+    dc.SetTextForeground(wxSystemSettings::GetColour(wxSYS_COLOUR_CAPTIONTEXT));
     dc.DrawText(page.caption, text_offset,
                 drawn_tab_yoff + drawn_tab_height / 2 - texty / 2 - 1);
 

I hope this patch will be applied before the next release!
I don't think this should be done.

First: we are in a feature freeze and only release-critical bugs should be fixed and even if it might be annoying for users of dark themes, it's not release-critical in my opinion, and any fixes should be tested long enough.

Second: I just tried the patch and after an error and the text: "Process terminated with status 1 (0 minutes, 0 seconds)" with a red background, the background of all newly added text in the Build log stays red.

debian 64 bit, svn r6202, wxWidgets 2.8.10, gcc 4.4.3

Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 09, 2010, 11:51:13 pm
Jens: have you tried my patch, do you experience the same problem (red background) with it?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 10, 2010, 12:01:13 am
I still haven't figured out how to set the colour of the notebook tabs properly - I can't find the place where the black text colour is hardcoded. This might even be in the wx libraries.

You can try this one, at least for C::B's own styles (MSVC anf FF2):

Thanks, I will try. I'm using the Simple Tabs style though, and I think the code for that is in the wx libraries. Anyway, that's a minor thing, the tab text is readable :)

Quote
I hope this patch will be applied before the next release!
I don't think this should be done.

First: we are in a feature freeze and only release-critical bugs should be fixed and even if it might be annoying for users of dark themes, it's not release-critical in my opinion, and any fixes should be tested long enough.

Of course it should be tested, but this is a small change, which wouldn't need a long time to test. And it's not something that changes any critical internals either, so I'd say now is as good a time to fix this than ever. I'm not a Code::Blocks developer though...

Quote
Second: I just tried the patch and after an error and the text: "Process terminated with status 1 (0 minutes, 0 seconds)" with a red background, the background of all newly added text in the Build log stays red.

debian 64 bit, svn r6202, wxWidgets 2.8.10, gcc 4.4.3

You're right, I can reproduce this. I'm attaching the patch again, this time the background colors are set correctly (loggers.cpp lines 62 and 89).

[attachment deleted by admin]
Title: Re: The 27 February 2010 build (6181) is out.
Post by: jens on April 10, 2010, 12:03:04 am
Jens: have you tried my patch, do you experience the same problem (red background) with it?
No (I don't like dark themes, so no need to test it until now, and really not very much time at the moment), but I already fixed the red-background issue.

Here is a snippet of the changed patch to loggers.cpp :
Code: [Select]
@@ -61,12 +78,14 @@
     // might try alternatively
     //italic_font.SetStyle(wxFONTSTYLE_SLANT);
 
+    wxColour default_text_colour = wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOWTEXT);
+    wxColour default_bg_colour = wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOW);
     for(unsigned int i = 0; i < num_levels; ++i)
     {
         style[i].SetFont(default_font);
         style[i].SetAlignment(wxTEXT_ALIGNMENT_DEFAULT);
-        style[i].SetTextColour(*wxBLACK);
-        style[i].SetBackgroundColour(*wxWHITE);
+        style[i].SetBackgroundColour(default_bg_colour);
+        style[i].SetTextColour(default_text_colour);
 
         // is it necessary to do that?
         //style[i].SetFlags(...);

EDIT:
our posts crossed each other
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 10, 2010, 12:17:20 am
No (I don't like dark themes, so no need to test it until now, and really not very much time at the moment), but I already fixed the red-background issue.
I also don't like the extremely dark (black) themes, but gray themes are OK for me :)

Code: [Select]
+    wxColour default_text_colour = wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOWTEXT);
+    wxColour default_bg_colour = wxSystemSettings::GetColour(wxSYS_COLOUR_WINDOW);
Isn't it better to use control->GetForegroundColour()/GetBackgroundColour()?

Also your notebook patch is not OK, with my theme and ff2 style: http://smrt.is-a-geek.org/codeblocks/screens/notebook_patch_bug.png

Of course it should be tested, but this is a small change, which wouldn't need a long time to test. And it's not something that changes any critical internals either, so I'd say now is as good a time to fix this than ever. I'm not a Code::Blocks developer though...
It is not so easy to test it, because there are lots of gtk2 themes + windows xp/vista/7...
Title: Re: The 27 February 2010 build (6181) is out.
Post by: foobar123 on April 10, 2010, 12:35:50 am
Isn't it better to use control->GetForegroundColour()/GetBackgroundColour()?

Yeah it might. I wrote this quickly and I'm not familiar with wxWidgets.

Quote
Of course it should be tested, but this is a small change, which wouldn't need a long time to test. And it's not something that changes any critical internals either, so I'd say now is as good a time to fix this than ever. I'm not a Code::Blocks developer though...
It is not so easy to test it, because there are lots of gtk2 themes + windows xp/vista/7...

Ok, this might be true for the "brightening" of colors (the BlendTextColour function). But when choosing default theme colors for background and text, one can't really do anything wrong? In any case, choosing black for the foreground and leaving the background to the theme, as it was done e. g. in the search result logger, is about the worst combination one could do, no?

This article is about web pages, but I think it applies here too: "If You Pick One Color, Pick Them All" http://www.w3.org/QA/Tips/color

Maybe we could agree on using GetXgroundColor() or wxSystemSettings::GetColour() for default text in loggers for now, and find a way to create contrasting warning/error messages later? Meaning, simple Red and Blue contrast pretty much any colour, so we can leave them as they are for now. Would be a step in the right direction IMHO.

If you don't want to do this, at least force the background colors to white. Even if that hurts my eyes ;o)
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 12, 2010, 10:38:20 am
I have a question: What codepage used by `Build log` text edit component?
I have a problem with it - when I start pre/postbuild step I can't recognize output of executed binary (output is in cyrilliс codepage). I can convert output by executing `chcp` command and then execute binary in windows batch file with the same name as binary's. But to do so I need to know codepage of C::B component.


[attachment deleted by admin]
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 12, 2010, 02:23:02 pm
I must report that after `global variables` dialog is closed config remains unsaved for unknown reason. And when C::B crashes all changes are loast. That's why I need after each modification of C::B config restart it.
I think it will be better to save config when dialog is closed.

The same can be made for projects and workspaces - I need save project manually every time I made changes in it (added file, removed file, changed project's config and so on).

C::B makes a show that all saved and IDE initialized after successful saving, but really it isn't.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 12, 2010, 02:35:27 pm
But if I run more than 1 instance of IDE and changed config in one of them it can be replaced by older one after closing them if it wasn't the lastest closed IDE.
To prevent this IDE can check date of last modification of config file when I select another instance of IDE and advice to apply new config or no (just the same way as for source files).

Good luck!
Title: Re: The 27 February 2010 build (6181) is out.
Post by: Zini on April 12, 2010, 02:43:15 pm
Actually the easiest solution would be to drop saving settings on application shutdown entirely and save them instead immediately when they are changed. This solves the problem of losing settings by a crash as well as any mess created by running two instances in parallel. Honestly, who came up with the idea of saving setting at shutdown time? (bet it was Microsoft ;) )

Regarding automatic saving of projects: This was already discussed before. See here:

http://forums.codeblocks.org/index.php/topic,10653.0.html

Unfortunately it didn't lead to anything.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 12, 2010, 06:46:25 pm
... And when C::B crashes all changes are loast....
C::B must not crash... Have you isolated and reported the crashes you experience?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 13, 2010, 05:57:16 am
oBFusCATed, you are not right - I use nightly build (even the stable version) and it will probably crash. So the better solution in this case is to save settings when I press OK and then (if successful) to initialize IDE. In this case we can report not only stack trace, but configuration of IDE (it can be useful for developers, I think)
Title: Re: The 27 February 2010 build (6181) is out.
Post by: ollydbg on April 13, 2010, 06:39:25 am
I have a question: What codepage used by `Build log` text edit component?
I have a problem with it - when I start pre/postbuild step I can't recognize output of executed binary (output is in cyrilliс codepage). I can convert output by executing `chcp` command and then execute binary in windows batch file with the same name as binary's. But to do so I need to know codepage of C::B component.

I also experience this kind of problem.
When I use a mingw gcc version which has Chinese language support. There are always unknown characters in the build log. The only thin I can do is : Delete the Chinese language files under C:\MinGW\share\locale
 :D
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 13, 2010, 09:27:15 am
oBFusCATed, you are not right - I use nightly build (even the stable version) and it will probably crash. So the better solution in this case is to save settings when I press OK and then (if successful) to initialize IDE. In this case we can report not only stack trace, but configuration of IDE (it can be useful for developers, I think)
No, I'm right, you have not reported why it crashes.  :lol: 8)
Developers don't need config files, most of the time, they need "steps to reproduce" (Saying "it will probably crash" doesn't help at all!)
Please start a thread, where you explain what you do to crash C::B!

Implementing the "Save on OK" feature has its drawbacks, too...
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 13, 2010, 09:42:31 am
Quote
you have not reported why it crashes.

In my message I'm not focused on some IDE crash, but on loosing of my settings each time crash happens :) and that is very unpleasant.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 13, 2010, 01:01:17 pm
OK, Live with the crashes... You can't be helped  :lol:
Title: Re: The 27 February 2010 build (6181) is out.
Post by: filofel on April 13, 2010, 05:15:55 pm
Quote
OK, Live with the crashes... You can't be helped

PMJI, but that's a problem I've been experiencing too:
When C::B abruptly terminates for any reason (might not even be C::B fault), most of the time, a part of the project is lost. Or at least, the latest modifications are lost (such as files recently appened to the project, etc.).
It would be nice if anything that is saved in the config would be written to disk and flush() committed immediately, to minimize the risk of ending up with an obsolete and/or corrupted config file. I think that this is what Critic meant.

C::B crashes very rarely under me (even though I'm running bleeding edge nigthly builds, 6203 as of today, courtesy of Jens Lody's repositories, mucho thanks Jens).
But in the rare occasions when I had a problem, I ended up with missing items in my project. Even though I have Autosave set to 4 mn on both sources and project, BTW.

I guess this can be simulated quite easily by abruptly ending the C::B process.  :)
Title: Re: The 27 February 2010 build (6181) is out.
Post by: MortenMacFly on April 15, 2010, 07:00:56 am
It would be nice if anything that is saved in the config would be written to disk and flush() committed immediately, to minimize the risk of ending up with an obsolete and/or corrupted config file. I think that this is what Critic meant.
Look: This would make it impossible to play with project configurations e.g. for optimisations. I personally do that quite often but if this would be saved every time I would always need to revert it back. I don't agree that this makes sense. The same would be that every time you are typing a character in the editor the editor shall be saved. This makes no sense.

The only solution I see is to adapt the autosave plugin to save project files in a certain interval, too. This can be toggled and is convenient.

I guess this can be simulated quite easily by abruptly ending the C::B process.  :)
Same thing here: Did you ever think when I kill a process I want exactly not to save anything?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: filofel on April 15, 2010, 08:23:07 am
<shrug>
I've been using *alot* of IDEs, and I've never experienced that kind of behavior before.
IOW, all those I know of do secure config modifications either instantly or at validation time.

Quote
The same would be that every time you are typing a character in the editor the editor shall be saved.
The comparison doesn't hold, IMO. Typical use case doesn't show the same change rate, by several orders of magnitude. And the config changes tend to be more important because they impact the whole project, and update losses are not proofed by a compiler.

Quote
Same thing here: Did you ever think when I kill a process I want exactly not to save anything?
If you consider killing C::B as a "normal" way to exit it (like a "quit without saving" menu item), then you are probably right. But as far as I'm concerned, I've never had to kill C::B (or any other IDE) for such a reason.
It looks to me the motivations you mention are more those of a developer of C::B who needs this behavior for testing C::B more conveniently than those of a vanilla user of C::B using it for developping anything else.

Nevermind...
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 15, 2010, 02:10:03 pm
Please, note that: sometimes at development process I add global variables or change them and when I close `global variables` dialog I expect they will be saved at that moment, but they don't. I think this example shows that behaviour of IDE in such situations is strange.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: oBFusCATed on April 15, 2010, 02:29:38 pm
<shrug>
I've been using *alot* of IDEs, and I've never experienced that kind of behavior before.
Please name some of them? Visual studio isn't doing it (all versions <=2005, don't know for newer ones).
I've not tested other IDEs in years.

If the Save on OK is implemented, what would be the behavior when there are two instances of C::B?
The second instance should detect the configuration change and then what?

To all: please keep in mind that when one software crashes this is a critical bug. It should be reported and fixed.
And developers fix crashes they know about...
Title: Re: The 27 February 2010 build (6181) is out.
Post by: stahta01 on April 15, 2010, 06:30:03 pm
Please, note that: sometimes at development process I add global variables or change them and when I close `global variables` dialog I expect they will be saved at that moment, but they don't. I think this example shows that behaviour of IDE in such situations is strange.

Note, never had the above behavior; but, had a behavior close to it.
Add a new global variables set; add entries to it.
Close the global variables window. Instead of using the new set it was using the old set of global variables.

After creating a new set of global variables, I must always remember to exit the window and then go back in and select the new global variables set.

Tim S.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 16, 2010, 06:56:06 am
May be my post is not clear (my english is poor) - I mean that global variables work fine (after I add new set it is applied by IDE after closing global variables dialog), but they are not saved to file system (save to prevent losing of made changes while IDE crash).

Another way - IDE can save these all setting to temporary files and when IDE crashes config is not lost, but at the next IDE startup it diagnoses that the crash happened and suggests to restore settings from temporary files (if data restored successfully - temporary files must be deleted). If settings are not changed after IDE startup temporary files mustn't exist - they must be created when user modifies IDE config.
The same can be applied to projects.

As for multiple instances of IDE - when settings of one of the running IDEs were saved the others must new settings (by supplying a question dialog box) to prevent overwriting.
I think it's normal and useful. It's a bit like in version control systems.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: critic on April 28, 2010, 11:59:51 am
 :oops: Excuse me for critics about Ctrl+Tab feature - it's my fault - I changed hot key from Ctrl+Tab to Alt+Left and Alt+Right and forgot about this.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: nanyu on April 28, 2010, 03:01:14 pm
May be my post is not clear (my english is poor) - I mean that global variables work fine (after I add new set it is applied by IDE after closing global variables dialog), but they are not saved to file system (save to prevent losing of made changes while IDE crash).

Another way - IDE can save these all setting to temporary files and when IDE crashes config is not lost, but at the next IDE startup it diagnoses that the crash happened and suggests to restore settings from temporary files (if data restored successfully - temporary files must be deleted). If settings are not changed after IDE startup temporary files mustn't exist - they must be created when user modifies IDE config.
The same can be applied to projects.

As for multiple instances of IDE - when settings of one of the running IDEs were saved the others must new settings (by supplying a question dialog box) to prevent overwriting.
I think it's normal and useful. It's a bit like in version control systems.

Can we just add a "Save" button on such dialogs ? or "Save all tabs setting" and "Save current tab setting"?

(after do save all...pls disable the "Cancel" button)?
Title: Re: The 27 February 2010 build (6181) is out.
Post by: nanyu on April 28, 2010, 03:21:45 pm
when talk about the “Global variables" setting. There is a situation make me crazy...

1. add 20 global variables(gv) items to the gv setting which named "default".
2. clone the default setting to "setting2"
3. add some new gv items to setting2, such as : wx26
4. open a workspace with 10 projects. (I'll say this workspace as "Workspace1").
5. set the each project use the "wx26" gv item. (such as : add wx26 to prj's search pathes)
6. everything OK now. save everything..
7. close the workspace (close everything)
8. switch global variable setting to "default"
9. open another existsd project which use the "default" setting.
10. close c::b after close current project.
11. restart c::b 
12. open the "Workspace1"  (I forget to switch gv setting to "setting2")
13. now, I have to been ask the "no found wx26 gv.." at least 10 times.
     the gv setting dialog will show at least 10 time.
    I have do 2 test:
    test1 : every time I switch the to the setting2, but everytime c::b switch it back to default ...
    test2 : I create the "wx26" item and add to "default" setting...but c::b ask me next project also.

============
 windows xp. c::b svn 6181
Title: Re: The 27 February 2010 build (6181) is out.
Post by: panda on April 29, 2010, 11:17:46 am
What does the " - Linux : none" mean? Can I  only download source code from svn? Howerver, I cannot download code from svn in corp.
Title: Re: The 27 February 2010 build (6181) is out.
Post by: secks on May 12, 2010, 05:27:00 pm
see http://apt.jenslody.de (http://apt.jenslody.de)
Title: Re: The 27 February 2010 build (6181) is out.
Post by: hakim on May 13, 2010, 11:51:07 am
Ubuntu -> https://launchpad.net/~simger/+archive/codeblocks
Title: Re: The 27 February 2010 build (6181) is out.
Post by: a14331990 on May 21, 2010, 01:40:45 pm
 :D
When is the next official build?
I have seen it in the svn log
Quote
r6261 | mortenmacfly | 2010-05-19 17:59:01 +0800 (Wed, 19 May 2010) | 1 line

* prepared new logo
svn log http://svn.berlios.de/svnroot/repos/codeblocks/trunk/ > changes.txt
or
http://apt.jenslody.de/ChangeLog
for details.
Is there any wiki pages like "Release Plans" or "Roadmap"?

Regards.
a14331990 a.k.a Leo
Title: Re: The 27 February 2010 build (6181) is out.
Post by: Folco on May 21, 2010, 05:23:01 pm
http://forums.codeblocks.org/index.php/topic,12156.0.html

We are eagerly waiting for a new stable release. :)