Author Topic: The 07 November 2010 build (6840) is out.  (Read 46123 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
The 07 November 2010 build (6840) is out.
« on: November 07, 2010, 11:30:02 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.

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 07 November 2010 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20101107_rev6840_win32.7z
  - Linux :
   none

Resolved Fixed:

  • Build system clean-up: Removed unnecessary automake files from sys, win32gui, wxwidgets project wizards.
  • fix for a folding-bug, where the folded block stays hidden, if the folding-header (brace or whatever) was deleted (see here: http://forums.codeblocks.org/index.php/topic,13551.msg91270.html#msg91270 , and others).
  • always have one free core of parallel builds
  • wxSmith: avoid some build warning, e.g. "type attributes ignored after type is already defined"
  • add option to remove variable prefix of the event handler function
  • add wxEVT_SCI_TAB and wxEVT_SCI_ESC event handler, thank danselmi help!
  • support strong enum parsing
  • fix cpu range error: occured if the cpu-count is greater than sixteen
  • apply patch for move abbreviations from core into a plugin (modify and improved), see: https://developer.berlios.de/patch/?func=detailpatch&patch_id=3068&group_id=5358
  • add abbreviatons-plugin to automake-system on linux (and others); build fix (include-file names are case-sensitive on linux); fixed typo
  • Abbreviatons-Plugin: fix bug, the keyword list box should be not sorted
  • avoid possible crash when file modified by external tools
  • improved cc search, moved all static variables to member variables, after switch parser, we should call init function again
  • fixed sometimes 'goto implementation' doesn't work
  • improved system header completion
  • 'goto declaration' and 'goto implementation' will goto the token position now
  • fixed wrong function parameter location records
  • fixed 'find references' or 'rename symbol' failed of function parameter
  • removed invalid copyright declare
  • fixed crash while opened xpm files, and make xpm files can be parsed
  • add svn:keywords for some new files
  • applied patch by danselmi: Add ToDo menu item so that keybinder plugin can re-assign a shortcut
  • improved function parameters parsing, support multi line parameter
  • fixed bug: #010036, see https://developer.berlios.de/bugs/?func=detailbug&group_id=5358&bug_id=10036
  • fixed mistake function parsing, e.g. "int i(8);", it should be variable, not function
  • add "No such file or directory" rules to capture build error
  • improved auto indent for "for/do/while/if..."
  • fixed get stripped arguments failed when parsing Multi-line parameters
  • add Token::GetFormattedArgs(), it will replaced from '\n' to '' for multi-line parameters
  • add "--multiple-instance" program arguments
  • Build system clean-up: Removed unnecessary automake files from ppc project wizard.
  • Fixed: Crash candidate in CC plugin.
  • Fixed: Crash candidate in cbstatusbar
  • wx-2.9 migration: Build fixes.
  • fixed the line number initialization error when use buffer parsing
  • multiple-instance parameters fixed
  • improved call tips, fixed sometimes can not show
  • applied PCH fix patch by oBFusCATed
  • rewritten NativeParser::GetCallTips, support multi-line call tips, fixed bug reported here: https://developer.berlios.de/bugs/?func=detailbug&group_id=5358&bug_id=9935
  • support constructor call tips
  • support shown template parameters in the Symbol Browser
  • add "__cpluscplus" predefined macro for C++ project
  • add "Build options" tab page, for solved too high of the option dialog
  • some default size improved for small display
  • improved ThreadSearch layout, making it more compact
  • splitting "General settings" to "Editor settings" and "Other settings" by wxNotebook
  • re-layout CodeCompletion-Plugin config dialog
  • ThreadSearch: avoid the error dialog interaction, to direct log output
  • improved to get destructor function under cursor
  • special handle destructor function for 'Goto declaration' and 'Goto implementation'
  • special handle constructor function for 'Goto declaration' and 'Goto implementation'
  • improved real-time reparsing
  • when create a variable with an invalid content, give a choice for the user
  • add "Token::GetStrippedArgs()" for remove default value, improved function implementation
  • build option fix
  • fix auto indent error, reported here: http://forums.codeblocks.org/index.php/topic,13548.msg91682.html#msg91682
  • support function overload parsing
  • fix: after moving abbreviations into a plugin, the plugin was missing in debian install files
  • special handle function overloading for 'Goto declaration' and 'Goto implementation'
  • bug fix for function overloading
  • compatible with the latest version of the wxSmith
  • add "*.bmarks" to ignore list, add ".objs, devel, output" to ignore list of "src"
  • auto find the references after rename symbol
  • update deleted pages in project options
  • apply patch #003038 to support open file's containing folder, see: http://forums.codeblocks.org/index.php/topic,12983.0.html
  • avoid possible crash
  • wxSmith: strip trailing blanks when flush to file
  • fine-tuning interface layout of "Other settings"
  • making open containing folder can be configurable of the commands
  • fixed big title info can not setting background color, and center align on Linux, avoid the issue record here: http://wiki.wxwidgets.org/WxStaticText
  • fixed big title info for "Compiler and debugger settings"
  • fine-tuning configure dialog interface for "Code-Completion" plugin
  • DoxyBlocks-plugin: make generated comments undoable in one step

Regressions/Confirmed/Annoying/Common bugs:



    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 07 November 2010 build (6840) is out.
    « Reply #1 on: November 07, 2010, 12:11:26 pm »
    Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.

    Max

    • Guest
    Re: The 07 November 2010 build (6840) is out.
    « Reply #2 on: November 07, 2010, 04:30:07 pm »
    Any chance to have a nightly of the debugger branch?

    Max

    Offline Folco

    • Regular
    • ***
    • Posts: 343
      • Folco's blog (68k lover)
    Re: The 07 November 2010 build (6840) is out.
    « Reply #3 on: November 07, 2010, 05:31:39 pm »
    When executing a make uninstall, some folders remain :
    /usr/local/share/codeblocks/ (with folders inside)
    /usr/local/include/[codeblocks | wxsmith | wxSmithContribItems]/
    /usr/local/lib/[codeblocks | wxSmithContribItems]

    $(HOME)/.codeblocks isn't removed, perhaps this is the expected result ?

    But for folders in /usr/loca, this is normal ?

    (all this is true for svn 6838, currently compiling 6840).
    Kernel Extremist - PedroM power ©

    sandford

    • Guest
    Re: The 07 November 2010 build (6840) is out.
    « Reply #4 on: November 07, 2010, 06:04:24 pm »
    Could someone expand on the bullet point: "always have one free core of parallel builds". Does this mean that even if I manually specify C::B to use one thread per core, it will only use N-1 cores? Or does this only apply to the default parallel build settings?

    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 07 November 2010 build (6840) is out.
    « Reply #5 on: November 07, 2010, 06:16:02 pm »
    Could someone expand on the bullet point: "always have one free core of parallel builds". Does this mean that even if I manually specify C::B to use one thread per core, it will only use N-1 cores? Or does this only apply to the default parallel build settings?
    The log shows work in progress.
    After some discussion between the devs, we decided to kee a conservative default value (if no conf-file exists) of 1.
    The range you can chose is between one and 16 or between one and the cpu-(or better core-)count, if it is greater than 16.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 07 November 2010 build (6840) is out.
    « Reply #6 on: November 07, 2010, 06:55:51 pm »
    By the way is it possible to make this option per compiler?
    On windows if you have gcc and visual studio, you have to modify it when switching compilers,
    because VC doesn't work, when the option is !=1.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline Jenna

    • Administrator
    • Lives here!
    • *****
    • Posts: 7255
    Re: The 07 November 2010 build (6840) is out.
    « Reply #7 on: November 07, 2010, 07:35:22 pm »
    When executing a make uninstall, some folders remain :
    /usr/local/share/codeblocks/ (with folders inside)
    /usr/local/include/[codeblocks | wxsmith | wxSmithContribItems]/
    /usr/local/lib/[codeblocks | wxSmithContribItems]

    $(HOME)/.codeblocks isn't removed, perhaps this is the expected result ?

    But for folders in /usr/loca, this is normal ?

    (all this is true for svn 6838, currently compiling 6840).
    There is/was a discussion about that: http://www.mail-archive.com/automake@gnu.org/msg00423.html

    I suggest using checkinstall for the last step (make install), it exists for almost every distribution, and can create packages for almost any package-manager: http://checkinstall.izto.org/ .

    Offline Folco

    • Regular
    • ***
    • Posts: 343
      • Folco's blog (68k lover)
    Re: The 07 November 2010 build (6840) is out.
    « Reply #8 on: November 07, 2010, 08:52:22 pm »
    Thank you !
    Kernel Extremist - PedroM power ©

    Offline Loaden

    • Lives here!
    • ****
    • Posts: 1014
    Re: The 07 November 2010 build (6840) is out.
    « Reply #9 on: November 08, 2010, 01:02:50 am »
    because VC doesn't work, when the option is !=1.
    Works well for me, which your OS? VC version?
    I'm testing on XPSP3, VC10.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 07 November 2010 build (6840) is out.
    « Reply #10 on: November 08, 2010, 09:44:47 am »
    Loaden: VC 10 is something like VisualStudio 4.0, because VisualStudio 6.0 has compiler with version 12.00.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5913
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 07 November 2010 build (6840) is out.
    « Reply #11 on: November 08, 2010, 09:53:37 am »
    Loaden: VC 10 is something like VisualStudio 4.0, because VisualStudio 6.0 has compiler with version 12.00.
    VC10 I think is Visual C++ 2010.
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline Loaden

    • Lives here!
    • ****
    • Posts: 1014
    Re: The 07 November 2010 build (6840) is out.
    « Reply #12 on: November 08, 2010, 10:19:51 am »
    Loaden: VC 10 is something like VisualStudio 4.0, because VisualStudio 6.0 has compiler with version 12.00.
    VC10 I think is Visual C++ 2010.

    That's my meaning.  :lol:

    Offline ikipiki

    • Single posting newcomer
    • *
    • Posts: 4
    Re: The 07 November 2010 build (6840) is out.
    « Reply #13 on: November 08, 2010, 11:19:11 am »
    Thanks for this build, it is pretty stable.
    Just one thing that I have note. When editor option “interpret #if, #else, #endif to gray...” is on, editor ignores defines in project build options.

    Offline ptDev

    • Almost regular
    • **
    • Posts: 222
    Re: The 07 November 2010 build (6840) is out.
    « Reply #14 on: November 08, 2010, 11:21:20 am »
    The unofficial installer (nightly build with the added plugins cbDiff, ColorCoder, FileManager, PowerShell, SpellChecker and XPMEditor) has been updated to svn revision 6840. The announcement can be found here.

    Direct download link here.

    Offline tanq

    • Multiple posting newcomer
    • *
    • Posts: 18
    Re: The 07 November 2010 build (6840) is out.
    « Reply #15 on: November 08, 2010, 01:41:37 pm »
    By the way is it possible to make this option per compiler?
    On windows if you have gcc and visual studio, you have to modify it when switching compilers,
    because VC doesn't work, when the option is !=1.
    U can add new build targets and assign different compiler to them.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 07 November 2010 build (6840) is out.
    « Reply #16 on: November 08, 2010, 03:01:02 pm »
    Your post is totally unrelated.
    I know how to setup a project with different compilers...
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline elettronica67

    • Single posting newcomer
    • *
    • Posts: 3
    Re: The 07 November 2010 build (6840) is out.
    « Reply #17 on: November 08, 2010, 10:25:02 pm »
    Hi,
    does someone know when the debugger branch will be merged with the main branch?

    Thanks in advance
    Paolo

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 07 November 2010 build (6840) is out.
    « Reply #18 on: November 08, 2010, 11:38:13 pm »
    Yes it will, someday :)
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline Folco

    • Regular
    • ***
    • Posts: 343
      • Folco's blog (68k lover)
    Re: The 07 November 2010 build (6840) is out.
    « Reply #19 on: November 09, 2010, 12:41:22 am »
    The Debian way: "when it's ready" ^^
    Kernel Extremist - PedroM power ©

    Offline Monolith

    • Single posting newcomer
    • *
    • Posts: 2
    Re: The 07 November 2010 build (6840) is out.
    « Reply #20 on: November 09, 2010, 09:24:41 am »
    Misspelling in Settings->Editor->Source Formatter->Formatting "Insert space padding after paren headers only."

    Also I was wondering if there was a way to edit "smart" indent tabbing style. I would like the "smart" indent to kick over only 1 tab on continued lines and not line up under the parameters.

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 07 November 2010 build (6840) is out.
    « Reply #21 on: November 09, 2010, 11:09:48 am »
    Yes you can turn of the parameter alignment...

    It is somewhere in Settings -> Editor, look for checkbox "smart indent brace" or something like that...
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline huliming2004

    • Single posting newcomer
    • *
    • Posts: 6
    making order of search directories
    « Reply #22 on: November 10, 2010, 02:57:15 am »
    Reacently i was immigratting a qt-mingw project to vs2005, i found that
    you cannot make the order of search directories. i found many file conficts
    like imessag.h, parser.h with vs2005 PlatformSDK, i adjust the search order to
    avoid it and found it was very inconvenient. Do you provide a fuction that can
    move directory items up and down like vs2005 or delphi do?
    (build options -> search directories)

    best regards!

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 13413
      • Travis build status
    Re: The 07 November 2010 build (6840) is out.
    « Reply #23 on: November 10, 2010, 09:18:41 am »
    I think there are two buttons on the right side -> "up" and "down"
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline Folco

    • Regular
    • ***
    • Posts: 343
      • Folco's blog (68k lover)
    Re: The 07 November 2010 build (6840) is out.
    « Reply #24 on: November 10, 2010, 05:17:08 pm »
    I think I have a problem with "current project".

    I have two opened projects (but I don't use a workspace file to open both in the same time : I open .cbp files separately).

    I have an own "build" tool binded to the F5 key. Here its parameters :

    As you can see, it uses ${PROJECT_DIR} to be sure that the 'build.sh' script is the one of the current project.
    (edit -> on this shot, I have forgotten the '$' symbol before {...}. But behaviour is still same after having added it :()

    In CB, my current project is 'Par' (it's written in bold font), the one which is not current is 'pdtlib' (simple font).

    But when I press F5, the 'build.sh' script is the one of Pdtlib, not the one of Par. Is it a bug, or am I totally wrong ?

    I tried to toggle current activated project, by double-clicking or right-clicking the project name, it's always assemble Pdtlib, never Par.

    « Last Edit: November 10, 2010, 05:21:10 pm by Folco »
    Kernel Extremist - PedroM power ©

    Offline Folco

    • Regular
    • ***
    • Posts: 343
      • Folco's blog (68k lover)
    Re: The 07 November 2010 build (6840) is out.
    « Reply #25 on: November 10, 2010, 05:30:26 pm »
    hmmm...

    The problem doesn't occur anymore if I specify the 'working dir' in the Tools parameters... so now I can get the right script to be launched.

    But before this solution, C::B log was quite strange :
    Quote
    Launching tool 'Build': /usr/bin/konsole --hold --workdir /mnt/[...]/PAR/src/ -e build.sh (in /mnt/[...]/PDTLIB/src/)
    Why didn't in work correctly ?? --workdir is a valid switch... http://www.digipedia.pl/man/doc/view/konsole.1/

    How to check that C::B really executes that ?
    « Last Edit: November 10, 2010, 05:36:18 pm by Folco »
    Kernel Extremist - PedroM power ©

    Offline huliming2004

    • Single posting newcomer
    • *
    • Posts: 6
    Re: The 07 November 2010 build (6840) is out.
    « Reply #26 on: November 10, 2010, 06:18:53 pm »
    I think there are two buttons on the right side -> "up" and "down"
    thanks! I have used codeblocks for about 2 years without noticing it,
    maybe it is because i alway uses "this is a custom Makefile", and write *.pro files,
    qmake it, then compile. Anyway thanks again.

    beanbaby

    • Guest
    Re: The 07 November 2010 build (6840) is out.
    « Reply #27 on: November 11, 2010, 09:30:15 am »
    Thx, I find this tool is perfect!!

    Offline SotM

    • Single posting newcomer
    • *
    • Posts: 2
    Re: The 07 November 2010 build (6840) is out.
    « Reply #28 on: November 11, 2010, 12:17:19 pm »
    I think I found a bug.
    Let's say I have a workspace and it is opened, there are 2 projects (regular C). Names are: Project1, MyLibrary.
    Project1 uses some functions from MyLibrary.
    I opened a C file from Project1, then right clicked on a function (which can be found within Project1), and select 'Find implementation...', and it jumps right to the implementation of that particular function.
    BUT, if I do the same (right click and select 'Find impl..') on a function which can be found in MyLibrary it says "Not found <function name>".
    And if I jump to project MyLibrary and try to "Find" that function within this project then everything will be fine. But, again, if I try to find a function "outside" this project then I get a message "Not found ... " :(
    If I do the same procedures with 'Find declaration ...' then everything is just fine.

    It did work fine with other CodeBlocks builds, but last 2 or 3 beta builds don't work fine.

    Or maybe I'm wrong and I need to turn on some special features.
    Ideas/comments?
    « Last Edit: November 11, 2010, 12:19:29 pm by SotM »

    Offline NerdIII

    • Single posting newcomer
    • *
    • Posts: 9
    Re: The 07 November 2010 build (6840) is out.
    « Reply #29 on: November 11, 2010, 05:17:21 pm »
    I just tried the gentoo ebuild for the svn version and it worked flawless. The code completion is really marture now and Code::Blocks is my preferred IDE on Linux now. Thank you for all the time you spent on this project and the plugins!
    Especially the Alt+n symbol rename functionality is a very convenient addition.

    Some glitches I found in the code completion (svn 6843):
    - It sometimes tries to complete 'itself'. It happens when I type "int variab|;" and the caret is at the pipe symbol. Then the popup shows me "variab" as a suggestion.
    - Also the codecompletion is now at a point where it shouldn't get any slower. When I write a simple for loop with a integer counter-variable I already experience some lag.
    - Template classes seem to pose a problem. When I have a vector<...> it can't find it's methods.

    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5491
    Re: The 07 November 2010 build (6840) is out.
    « Reply #30 on: November 11, 2010, 07:55:58 pm »
    I think I found a bug.
    Let's say I have a workspace and it is opened, there are 2 projects (regular C). Names are: Project1, MyLibrary.
    Project1 uses some functions from MyLibrary.
    I opened a C file from Project1, then right clicked on a function (which can be found within Project1), and select 'Find implementation...', and it jumps right to the implementation of that particular function.
    BUT, if I do the same (right click and select 'Find impl..') on a function which can be found in MyLibrary it says "Not found <function name>".
    And if I jump to project MyLibrary and try to "Find" that function within this project then everything will be fine. But, again, if I try to find a function "outside" this project then I get a message "Not found ... " :(
    If I do the same procedures with 'Find declaration ...' then everything is just fine.

    It did work fine with other CodeBlocks builds, but last 2 or 3 beta builds don't work fine.

    Or maybe I'm wrong and I need to turn on some special features.
    Ideas/comments?


    I have noticed this too, indeed this is a nasty problem.
    I think this showed up during all the code completion refactorings. Let's hope our CC gurus put their brains too it.

    Offline Loaden

    • Lives here!
    • ****
    • Posts: 1014
    Re: The 07 November 2010 build (6840) is out.
    « Reply #31 on: November 12, 2010, 06:38:33 am »
    I think I found a bug.
    Let's say I have a workspace and it is opened, there are 2 projects (regular C). Names are: Project1, MyLibrary.
    Project1 uses some functions from MyLibrary.
    I opened a C file from Project1, then right clicked on a function (which can be found within Project1), and select 'Find implementation...', and it jumps right to the implementation of that particular function.
    BUT, if I do the same (right click and select 'Find impl..') on a function which can be found in MyLibrary it says "Not found <function name>".
    And if I jump to project MyLibrary and try to "Find" that function within this project then everything will be fine. But, again, if I try to find a function "outside" this project then I get a message "Not found ... " :(
    If I do the same procedures with 'Find declaration ...' then everything is just fine.

    It did work fine with other CodeBlocks builds, but last 2 or 3 beta builds don't work fine.

    Or maybe I'm wrong and I need to turn on some special features.
    Ideas/comments?


    I have noticed this too, indeed this is a nasty problem.
    I think this showed up during all the code completion refactorings. Let's hope our CC gurus put their brains too it.
    You should use two targets, but not two projects.
    Because now a project per a parser.

    Offline SotM

    • Single posting newcomer
    • *
    • Posts: 2
    Re: The 07 November 2010 build (6840) is out.
    « Reply #32 on: November 12, 2010, 08:38:59 am »
    You should use two targets, but not two projects.
    Because now a project per a parser.
    Can you explain more? What should I do?

    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5491
    Re: The 07 November 2010 build (6840) is out.
    « Reply #33 on: November 12, 2010, 09:01:14 am »
    It means where in the past most probably there was a parser that parsed all projects in the workspace, and as such had the information of everything available, now there is only 1 parser per project. And it seems the information stays ONLY within that project.

    As in your example :
    project 1 --> library
    project 2 --> executable

    Depending on the project that is active, only  1 set of information is available [there are always ripple through because of the header files].

    If you would change your setup of your project(s) to only 1 project which then has 2 targets : the library and the executable; then again all the information is available for the code completion.

    However, I don't agree to this, I think we should look for a secondary mechanism, to also check the other projects in the workspace. If there are a lot of projects in the workspace such a search might slow down things.
    But this limited search has been a pain in the *** ;-)

    In all the years that I used CB, or VS for that matter, and all the places I worked at, the typical approachwas : 1 project per library. And this library can be used by many many applications.

    So while I am working on application 1, I have a workspace with the code of that executable, together with all the libraries it is using.

    Someone else is working on application 2, similar setup. So that means that a library will end up as a project in several workspaces.

    If it was a target it could not be shared, unless everything is constantly duplicated, or everything is put into 1 project, but different applications should not end up in the same project. They have nothing to do with one another, even ignoring the fact of the amount of stuff that needs to be parsed in such a case.

    So my suggestion, let's have a mechanism that all projects are parsed in the workspace (starting with the active one, the other can be parsed in the background). In case this might however be too high a penalty on performance load, make it a setting so the user can choose to do it this way or not. And in future we can continue to work on speeding things up if needed. Other IDE can also parse this way, so it is possible ;-)

    To me this reduced functionality has been troublesome ;-) , but don't forget we did get a lot of improvements on the code completion side in return. So please, pretty please, can we take this one 1 step further on the ladder of improved completion ?

    « Last Edit: November 12, 2010, 09:44:43 am by killerbot »

    Offline Loaden

    • Lives here!
    • ****
    • Posts: 1014
    Re: The 07 November 2010 build (6840) is out.
    « Reply #34 on: November 12, 2010, 09:29:03 am »
    Maybe, we can make it configurable, but perhaps exist more issue about one workspace per one parser.
    I will trying it if i find some time.

    Offline NerdIII

    • Single posting newcomer
    • *
    • Posts: 9
    Re: The 07 November 2010 build (6840) is out.
    « Reply #35 on: November 12, 2010, 10:03:29 am »
    When do you need code completion from another project? It means you use a symbol from some other compilation unit, right? And that can only work if the other project is a library, right? That leads me to the idea that you could extend the code completion object of the application project to also query the code completion objects of all dependent libraries in order to find implementations of exported symbols.
    That might be more intuitive after all than using a checkbox to parse "all projects at once", which would lead to lib1 finding implementations in an independent lib2. I'm not so keen on the idea that the code completion loses exactness again, it would be a step backwards.

    code completion plugin
    -> application (-Lmylib, uses foo())
    -> library (-o libmylib.so/mylib.dll, export void foo())

    The code completion plugin object sits at the top and when the application cc object cannot find an implementation it could ask the cc plugin object to return
    a) the list of libraries the project is linked against and compare the names with the output filename of any open library project (exact match possible).
    - or -
    b) all dependent library projects.
    Then the application cc object queries the found library cc objects for exports with the requested name.

    Offline cacb

    • Lives here!
    • ****
    • Posts: 536
    Re: The 07 November 2010 build (6840) is out.
    « Reply #36 on: November 12, 2010, 07:46:37 pm »
    Some general observations.

    Code::Blocks is getting better and better, but I find some stability issues sometimes  :lol:. These comments refer to Windows XP and using MS Visual Studio 2008 Express compiler.

    - When I have many source files and/or wxSmith resource file open at the same time, I often want to close all. This tends to crash Code::Blocks, however  :shock:. I think this is a fairly old problem seen with many nightly builds.

    - I keep moving my project files between two machines (both Win XP) and find that C::B is messing with my settings/use of global variables. For example, in my project file I have this

    Code
    	<Add directory="$(#wx.include)" />
    <Add directory="$(#wx)\contrib\include" />
    <Add directory="$(#wx)\lib\vc_lib\mswd" />
       
    The problem is that C::B tends to replace this with the expanded full path, which obviously does not work on the other machine, so I have to edit the .cbp file over and over again to fix it back to what it was. But it keeps coming back. Mostly, this happens on one machine and not the other, for some reason.

    - When I open a workspace, very often I get an error message dialog that I did not use to get with the same setup before:
    Quote
    cl.exe - Unable To Locate Component
    This application has failed to start because mspdb80.dll was not found. Re-installing the application may fix this problem.
    OK
    Then I have to OK this dialog, and everything is apparently working, including compilation and linking.

    I have seen these problems with build 6840, but also with 6752 and earlier.

    Offline cacb

    • Lives here!
    • ****
    • Posts: 536
    Re: The 07 November 2010 build (6840) is out.
    « Reply #37 on: November 12, 2010, 08:39:50 pm »
    Some general observations.

    And one more problem, this one is fairly new but very annoying. It relates to wxSmith. Again seen on WinXP.

    If you for example create a wxPanel class and put a wxButton somewhere, you may not want to keep the Button variable as a member of the class, all you care about is the event it generates, and a member button is not needed. To do this, I simply uncheck the "Is member" checkbox in the wxSmith properties area. However: This [always?/sometimes?/often?] silently changes the Identifier of the button from, say ID_BUTTON1 to wxID_ANY and thus causes havoc in the event handling. This is a nasty bug I spent some time figuring out.

    Offline Loaden

    • Lives here!
    • ****
    • Posts: 1014
    Re: The 07 November 2010 build (6840) is out.
    « Reply #38 on: November 15, 2010, 03:49:07 pm »
    To me this reduced functionality has been troublesome ;-) , but don't forget we did get a lot of improvements on the code completion side in return. So please, pretty please, can we take this one 1 step further on the ladder of improved completion ?
    Here is an un-complete patch for this issue.
    Sorry, I have no time to do it now.
    Because some reason, I should leave a time.
    If other devs find time, please continue this improve.
    Best regards!