New Class browser enhancements

[MortenMacFly]

Dear all,
I really like the recent changes in the class browser to make it a floating window. That increases productivity, indeed. Anyway, there are 2 remarks (questions) I'd like to state:
1.) When I open a workspace the class broser is updated. That's OK. But when I close the workspace (so there is no project or file opened) the class browser still has the whole tree. Clicking on any method (...) results in nothing. If this is by design, then forget about it, otherwise the tree should better be cleared to avoid confusion.
2.) What would be really helpful in addition is that if I enter a word in "Search" and press enter (when the text filed is still active) that the action would be the same as to press the ">" button besides. This avoids the need for using the mouse to focus to that button... ;-)
Anyway: Great idea and work again, guys!
With regards, Morten.

[mandrav]

Will look into number 1.
Number 2 is fixed now.

Also the search has been improved. It now starts the search from the currently selected node (or the root node if no selection). Every time you press Enter (or click the search button) it goes to the next match, wrapping around when no more matches are found.

[MortenMacFly]

Will look into number 1.
Number 2 is fixed now.

I actually didn't think in such a short timeframe, but thank you!
Anyway: I realised the xrc file has changed in line 39 from

Code

<object class="wxTextCtrl" name="txtSearch"/>

...to:

Code

<object class="unknown" name="txtSearch"/>

...is that really correct or an issue?
With best regards, Morten.

[mandrav]

Anyway: I realised the xrc file has changed in line 39 from

Code

<object class="wxTextCtrl" name="txtSearch"/>

...to:

Code

<object class="unknown" name="txtSearch"/>

...is that really correct or an issue?
With best regards, Morten.

That's correct.

[mandrav]

I just noticed that there might be a case that the search could enter an infinite loop and freeze the app. I 'll look into it a little later. For the time being, avoid searching the class browser or take the risk knowingly

[MortenMacFly]

[...] or take the risk knowingly

I used it the whole day today - no freezes. I guess the risk is quite small, isn't it?! ;-)
BTW: I saw revision 2295 by now, maybe you're refering to that.
Anyway - just take your time, this feature is really worth it. That's an really useful enhancement no other IDE I know provides! It's of that kind you never know that you need it until you've used it the first time - then you'll never want to work without it...
With regards, Morten.

[MortenMacFly]

Well... I've just updated to revision 2296. Now C::B crashes on exit if I have had a project opened. This does not happen if I do not open a project. I tried a full rebuild - no luck. I've attached the report file C::B creates - it seems the destructor of the classbrowser fails, but this is just one line of code?! Any thoughts on that?
With regards, Morten.

PS.: BTW: I've applied patch #982 (http://developer.berlios.de/patch/?func=detailpatch&patch_id=982&group_id=5358) but even if I remove the patch C::B still crashes.

Edit: I forgot to add: Version 1.0 revision 2296 (gcc 3.4.5 Windows/unicode, build: Apr  4 2006 20:01:46).

[attachment deleted by admin]

[Michael]

Well... I've just updated to revision 2296. Now C::B crashes on exit if I have had a project opened.
Edit: I forgot to add: Version 1.0 revision 2296 (gcc 3.4.5 Windows/unicode, build: Apr  4 2006 20:01:46).

Hello,

I have just build C::B rev2296 (gcc 4.1.0 - wxWidgets 2.6.3-RC1) and I can partially confirm the crash. I have started C::B, opened a project and then exit C::B with File-->Quit, but no crash. I have re-tried with the same project, but this time by using the X button to exit C::B and still no crash. Then I have tried with another project and when exit C::B with File-->Quit, I have had no crash. But when I have used the X button to exit C::B, then I have had the crash .

It seems that in my configuration the crash did not always occur... :roll:

Best wishes,
Michael

[MortenMacFly]

But when I have used the X button to exit C::B, then I have had the crash .

That's partially right! If I use the "Quit" from the "File" menu I have no crash message, too. Anyway: A codeblocks.rpt file is still being created silently. If I use the "X" I get the crash and a message and the codeblocks.rpt file is created, too. Strange!
With regards, Morten.

Ps.: Slightly off-topic:

I have just build C::B rev2296 (gcc 4.1.0 - wxWidgets 2.6.3-RC1) and I can partially confirm the

Are you aware that 2.6.3 is officially released (including 2 patches already)? There is no need for RC1 anymore. ;-)

[Michael]

But when I have used the X button to exit C::B, then I have had the crash .

That's partially right! If I use the "Quit" from the "File" menu I have no crash message, too. Anyway: A codeblocks.rpt file is still being created silently. If I use the "X" I get the crash and a message and the codeblocks.rpt file is created, too. Strange!

I have had a look at your and my RPT and they look different :?. I will attach mine here.

Ps.: Slightly off-topic:

I have just build C::B rev2296 (gcc 4.1.0 - wxWidgets 2.6.3-RC1) and I can partially confirm the

Are you aware that 2.6.3 is officially released (including 2 patches already)? There is no need for RC1 anymore. ;-)

Yes, I know. I am just a bit too busy. I will do it tomorrow and for the same occasion trying the GCC 4.1.0's workaround .


[attachment deleted by admin]

[MortenMacFly]

I have had a look at your and my RPT and they look different :?.

I've compared them, too. It seems your crash comes a "little later". Maybe you computer is "faster" than mine. ;-) But seriously: It seems like a timing problem of concurrent threads or something. That's really hard to track down, unfortunately. Maybe the guru (mandrav) is smart enough... I hope so.
With regards, Morten.

[MortenMacFly]

NEWS!
I think the crash ios related to the changes done in R2296. Could you try (if possible) to compile revvision 2295, please? It seems the crash is not present there to me... I'll do some further testing. Unfortunately I have to leave now until friday (a business trip, I am already  a bit late). I can only hope it's solved by then.
With best regards, Morten.

[Michael]

I've compared them, too. It seems your crash comes a "little later". Maybe you computer is "faster" than mine. ;-) But seriously: It seems like a timing problem of concurrent threads or something. That's really hard to track down, unfortunately.

My laptop is not too fast (a comment from Thomas) and unfortunately I cannot change it. It is a Dell Latitude D600 with Pentium M 1.80GHz and 1024MB RAM.

Maybe the guru (mandrav) is smart enough... I hope so.

I am sure he is .

Best wishes,
Michael

[Michael]

I think the crash ios related to the changes done in R2296. Could you try (if possible) to compile revvision 2295, please? It seems the crash is not present there to me...

It seems you are right. I have revert to rev2295 and tried at least 10 times to open a different project and then exit C::B with both File-->Quit and the X button without having a single crash .

rev2296 fixed a crash on exit in Linux. May be Windows did not appreciate... :roll:

Best wishes,
Michael

[tiwag]

i've just built svn rev 2303 and it still crashes  on exit in the codecompletion.dll , if any project is still opened when exiting CB.

[update info]
after analyzing the codeblocks.rpt
addr2line gives this info

crash occured at
trunk/src/plugins/codecompletion/classbrowser.cpp:126

[mandrav]

Should hopefully be fixed in r2305. Tiwag, can you confirm?

[tiwag]

Should hopefully be fixed in r2305. Tiwag, can you confirm?

just built and tested svn rev 2306 - no more crashes 

thanks Yiannis !

[MortenMacFly]

just built and tested svn rev 2306 - no more crashes 

For me too! (I'm back now ;-))
Thanks a lot!!! Now I'm very interested in what exactly you've changed. I'll consult SVN change history for this.
Let's say with Tina Turners words: "You're simply the best." (which currently plays on my internet radio mystically...), ;-)
With regards, Morten.

[mandrav]

Now I'm very interested in what exactly you've changed. I'll consult SVN change history for this.

One of the recent symbols browser fixes, was to put the code that builds it in a separate thread (so the UI doesn't block anymore while rebuilding the symbols browser - mainly seen when saving files).
For this crash to be fixed, the builder thread needed to terminate on shutdown but it didn't have the chance. Now it has .