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

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5179
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: 5179
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

  • Regular
  • ***
  • Posts: 395
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: [Select]
<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

  • Regular
  • ***
  • Posts: 395
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!