The 20 July 2006 build is out.

[killerbot]

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

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

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

For support of ansi builds, a link to the ansi windows wxWidget dll (2.6.2) for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw26_gcc_cb.7z

The 20 July 2006 build is out.
  - Windows : http://prdownload.berlios.de/codeblocks/CB_20060720_rev2774_win32.7z
  - Linux :
         http://prdownload.berlios.de/codeblocks/CB_20060720_rev2774_Ubuntu6.06.deb (not this time)
         http://prdownload.berlios.de/codeblocks/CB_20060720_rev2774_fc4+5.rpm (not yet)


Resolved Fixed:

• KeyBinder v0.22 - Temporary hack to ignore redefinition of the "Quit" menu item as it causes crashes during CodeBlocks  termination.
• codeblocks app returns batch-build exit code (when batch-build was active)

Regressions/Confirmed/Annoying/Common bugs:

• toolbar-images-not-changing-state (is a wx problem/Win XP problem)
• there are several issues with Code Completion (is being redesigned : work in progress)
• menu items with icon not correctly aligned (since wx263)

[cstudent]

Code::Blocks .deb for Ubuntu 6.06 (i386) rev 2774 build can be found here:

http://www.filefactory.com/file/14e7e2


Sorry, had to put it on a different file host. Savefile.com has been having problems the past couple of days.



cstudent

[cstudent]

Savefile.com finally came through.

CB_20060720_rev2774_Ubuntu6.06_i386.deb available here as well:

http://www.savefile.com/projects.php?pid=766262

[agent007se]

(Valid with other (last) nigtlies)

Is it normal that when I right click on the Project->Add files... dialog ?

[killerbot]

(Valid with other (last) nigtlies)

Is it normal that when I right click on the Project->Add files... dialog ?

what's wrong ?

[agent007se]

(Valid with other (last) nigtlies)

Is it normal that when I right click on the Project->Add files... dialog ?

what's wrong ?

I didn't complete my words lol I'm sorry :?

Here's the full procedure :

OS : win xp sp1

-Launch C::B
-(in the opened by default workspace) : goto Project menu -> Add files... -> do a right click (to call the context menu) on a blank space near files
-see the bug-window "Woah!" :

-click on "Abandonner" (:p) (lol) (means cancel)
-the context menu shows up
-continune working with C::B


 :shock:

[Pecan]

(Valid with other (last) nigtlies)

Is it normal that when I right click on the Project->Add files... dialog ?

what's wrong ?

I didn't complete my words lol I'm sorry :?

Here's the full procedure :

OS : win xp sp1

-Launch C::B
-(in the opened by default workspace) : goto Project menu -> Add files... -> do a right click (to call the context menu) on a blank space near files
-see the bug-window "Woah!" :

-click on "Abandonner" (:p) (lol) (means cancel)
-the context menu shows up
-continune working with C::B


 :shock:

I tried to recreate this, but could not. I'm running XPsp2 with SVN however.

[agent007se]

(Valid with other (last) nigtlies)

Is it normal that when I right click on the Project->Add files... dialog ?

what's wrong ?

I didn't complete my words lol I'm sorry :?

Here's the full procedure :

OS : win xp sp1

-Launch C::B
-(in the opened by default workspace) : goto Project menu -> Add files... -> do a right click (to call the context menu) on a blank space near files
-see the bug-window "Woah!" :

-click on "Abandonner" (:p) (lol) (means cancel)
-the context menu shows up
-continune working with C::B


 :shock:

I tried to recreate this, but could not. I'm running XPsp2 with SVN however.

Thus this seems to be related so sp1. So many people are still with the sp1 or reverted back to it because of the quality of the sp2 (I'll not justify here because it's not the topic).

Can the users with sp1 confirm this ?
I'm learning C++ but I really don't have the skills to even try to debug this... maybe in some months I'll be more useful :s. Reporting bugs is good but proposing a patch is much more useful  :? ...

For the moment I'm just avoiding to right click (not vital) in this dialog .

[JPlaroche]

Hello, first thank-you for the correction. 

All works. 

Now I had again a small probleme that I have determined as that. 

the meme error this is reproduced and I have only to eliminate these 2 files

in C: \Documents and Settings\samourai\Application Data\codeblocks

default.conf

default.worspace

 DragScroll.ini

apres all worked perfectly

I wish that my translator oneself ok for your comprehension thank-you again for the modification of "quit"


================================================================================
================================================================================
probleme du 19 juillet   copy message  http://forums.codeblocks.org/index.php?topic=3610.0

It's crashing for me under Windows XP when I quit. If I try the 17th of July build --> no problem...

and then I wrote this becasue of this :
Quote
# KeyBinder - v0.21 - Removed all dependencies on pushEventHander to avoid leaking handlers on unnotified window closuress
# Fixed multiple key profiles not being updated correctly when switching profiles without restarting CB

Quote from: killerbot on July 19, 2006, 10:36:54 AM
could you try this , but with the keybinder plug-in disabled ??
do you have an rpt file ? if so what does it say ?

Quote from: JPlaroche on July 19, 2006, 02:09:25 PM
open ide

compile my project    debug or release

ok

is quitte = scrash

os/winxp



@Pecan :
Since already 2 users started to have problems since the above mentioned changes, could it be it's purely because of this. They probably already redefined ctrl-Q (If they already done this in the first place?) and only now it seems to become a craashing problem Wink

[killerbot]

could you re-explain what the current (new) problem is you discovered ??

[JPlaroche]

could you re-explain what the current (new) problem is you discovered ??

I again had the meme probleme scrash "quit"

I was said that it was not possible with the correction

therefore I eliminated from file

C: \documents and Settings\xxxxxxxx\Application Data\codeblocks

*. Conf *. ini *. workspace (?) 

then again I have tested

all works normally (OK) :lol:    merci

[Pecan]

could you re-explain what the current (new) problem is you discovered ??

I again had the meme probleme scrash "quit"

I was said that it was not possible with the correction

therefore I eliminated from file

C: \documents and Settings\xxxxxxxx\Application Data\codeblocks

*. Conf *. ini *. workspace (?) 

then again I have tested

all works normally (OK) :lol:    merci

I can only guess that this means the cbKeybinder*.ini file was completely corrupted. Or some such. There's no way to know. When he deleted the *.ini files, he also deleted any additional "quit" keys.

Does anyone else have "quit" key crashes since the 19july nightely?

[JPlaroche]

could you re-explain what the current (new) problem is you discovered ??

I again had the meme probleme scrash "quit"

I was said that it was not possible with the correction

therefore I eliminated from file

C: \documents and Settings\xxxxxxxx\Application Data\codeblocks

*. Conf *. ini *. workspace (?) 

then again I have tested

all works normally (OK) :lol:    merci

I can only guess that this means the cbKeybinder*.ini file was completely corrupted. Or some such. There's no way to know. When he deleted the *.ini files, he also deleted any additional "quit" keys.

Does anyone else have "quit" key crashes since the 19july nightely?

I can furnish the put on file conf and ini of the versions 2758 before scrach

[jomabrueloe]

Hi,

I'm getting the "quit error" as well, since the 18th release; it has not been fixed for my system with this one (20th). I have no keybinding active - at this time.

Jo

[marfig]

I too get the error.

When I remove default.workspace from application\data, the problem goes away. I restart codeblocks, answer Yes to the request to save the workspace and the problem goes away.

The solution seems thus to delete this file.

EDIT: I believe the problem can be partly reproduced in the July, 18 NL by:

delete default.workspace -> start codeblocks -> yes to save workspace -> Open a project -> quit -> (You will get a beep and nothing happens) -> quit again.

This is probably when it starts

[Pecan]

I too get the error.

When I remove default.workspace from application\data, the problem goes away. I restart codeblocks, answer Yes to the request to save the workspace and the problem goes away.

The solution seems thus to delete this file.

Hi,

I'm getting the "quit error" as well, since the 18th release; it has not been fixed for my system with this one (20th). I have no keybinding active - at this time.

Jo

Ummm, there seems to be more then a keybinder problem here.

KeyBinder has no relationship to either *.workspace or *.conf. It neither reads nor writes to them.

KeyBinder only reads/writes to cbKeybinder*.ini. Deleting *.workspace or *.conf would have no effect what-so-ever on KeyBinder.

For the future, if these problems re-appear, please disable keybinder in the "Plugins->Manage Plugins" Menu item, then see if the crash disappears/remains.

In the case where there are no keybindings, keybinder never sees the quit key.  The quit menu item is completely handled by the wxidgets menu system. This particular crash discription appears to be something different.

<snip>
EDIT: I believe the problem can be partly reproduced in the July, 18 NL by:

delete default.workspace -> start codeblocks -> yes to save workspace -> Open a project -> quit -> (You will get a beep and nothing happens) -> quit again.

I am unable to reproduce the above with the SVN equivalent of the 20th July nightly build.

Keep talking people, the light will eventually come on...

thanks
pecan

[marfig]

I don't believe this has anything to do with the keybinder. I was getting a crash when using Quit from the file menu too.

Also, I cannot reproduce this on the July, 20 NL. Only on the 18th. Or with the 20th version IF I'm using a default.workspace created with a 18th NL.

[killerbot]

can you post in here the content of that default workspace

[marfig]

Ok... give me a few. going to downgrade and reproduce the error.

[marfig]

Let's see...

I start fresh by deleting default.workspace and downgrading to July, 17th NL.

I start codeblocks and answer Yes to the request to save the workspace. I quit without problems. The file is now:

Code

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
	<Workspace title="" />
</CodeBlocks_workspace_file>

I restart codeblocks, open a project and quit. I answer Yes to the request to save the workspace and quit without problems. The file is now:

Code

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
	<Workspace title="Default workspace">
		<Project filename="..\..\..\..\c++\middleages\middle.cbp" active="1" />
	</Workspace>
</CodeBlocks_workspace_file>

I upgrade to the 18th. Everything goes well. It doesn't crash on quit. I make no changes to the workspace.

I upgrade to the 20th (I never used the 19th. Was away). Everything goes well. I open another project and try to quit from the file menu. And It crashes.

At this point of the crasj, my default.workspace is:

Code

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
	<Workspace title="Default workspace">
		<Project filename="..\..\..\..\c++\middleages\middle.cbp" />
		<Project filename="..\..\..\..\MT\mt.cbp" active="1" />
	</Workspace>
</CodeBlocks_workspace_file>

Any subsequent restart of codeblocks and quit, crashes.

[marfig]

As an update to the previous post, if then I proceed to delete default.workspace all will be well. A new one is created when I restart codeblocks and I apparently can quit normally after opening one of my projects.

But if again I open another project, the problem resurfaces.

Apparently this is something to do with having more than one <Project filename= ... > under <Workspace title="Default workspace">

All quits were done under the file menu.

[killerbot]

good news and bad news :

Good : I can reproduce

Bad : will look into it earliest tomorrow ;-)

I never came across since I always startup with a blank workspace.

[EDIT] : though I don't have the crash all the time

The fact that 2 or more projects might be in there could be a requirement for having the crash. If you can please experiment a bit more (and with older versions) and post your feedback. Many thanks.

[marfig]

Ok... some experimenting follows
I started fresh from all NLs (default.workspace was deleted before firing up for the first time)

NL 17, July.
Doesn't crash. However, it misbehaves.

Fire up -> open project -> quit -> fire up -> open second project -> quit -> (There is a beep and doesn't quit) -> Quit again.

It then leaves the program, but if you go and check your default.workspace, it wasn't updated with the second project as it should. Consequently, any subsequent runs of codeblocks don't crash.

NL 18, July
Doesn't crash. Exactly the same as the 17th. With this little eccentricity: It doesn't beep this time  :lol:

NL 19, July
Doesn't crash. This one is more insidious. It gives no warning. Closes normally after opening 2nd project. An attentive user will wonder why it didn't ask him to save the workspace. But that's about it. default.workspace was not updated.

NL 20, July
You already know what happens here.
It's the one I like most... because this time it crashes. Between not knowing and knowing... I choose the red pill

Have fun with this one.

[killerbot]

Unfortunately I was no longer able to reconstruct the crash. But while taking a good look at the code I found several issues and hopefully fixed them. Could you try again with the build of the 25th ??

[marfig]

Unfortunately no. Having more than one project under the default workspace crashes on quit.

My default.workspace file:

Code

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<CodeBlocks_workspace_file>
	<Workspace title="Default workspace">
		<Project filename="..\..\..\..\MT\mt.cbp" />
		<Project filename="..\..\..\..\c++\middleages\middle.cbp" active="1" />
	</Workspace>
</CodeBlocks_workspace_file>

[MortenMacFly]

Hmmm... I still can't reproduce, too. Could you please explain your folder structure, thus give us the full path to:
- your C::B installation
- your default workspace file
- your two projects in question
Maybe this will help to enable reproducing this issue (I tried with a path like "1\2\3\4\5" but this seems to work very well).
With regards, Morten.

[killerbot]

or could you provide us with a zip fiole containing your projects (with as much of your code removed as possible) and see if with those dummy projects it still crashes.

Could you also try it out with a clean CB installation (nightly in new directory and remove/rename your default.conf) ??

I had the crash exactly once, but after that I was no longer able to reproduce it. Then I did some fixes and also not able to reproduce after these fixes ;-) . The fixes I have done are these :

- constructor of cbWorkspace now initializes all members, when you had no default.conf yet, the Load part of the constructor would fail because it did not find the file (duh) and several members remained uninitialized, a bit later the IsModified was checked and the modified member was by accident true this resulted in the startup of CB to ask to save the defaul.conf, while actually nothing had happened to it. Maybe some of these uninitialized behaviour could have caused the crashes. Due to the failure of the loading (NotOk) the project manager had no valid pointer value for m_pWorkSpace

- continueing on the previous issue, when a project was then loaded, nothing happened to the workspace because of the no valid m_pWorkSpace pointer, and at shutdown of CB the same thing happened, nothing got saved in the default.workspace since the m_pWorkSpace  was 0.

- the workspace loaders :
  + one of them had a member for a version number which was totaly unused ->removed
  + they contained a title member which they only used at Open and could be "Get" but at save one had to specify the title as an argument --> title member has been removed as a member and is now an I/O argument to the Open method where the only client of those workspaceloeaders (cbWorkspace) will deal with it, cbWorkspace not itselves start's with it's title being "Default Workspace". So things are a bi more consistent.
   [SideNote : during debugging those workspace loaders would return intheir GetTitle method either their m_Title or in the case it was empty "Default workspace", but I saw oit ending up injust the first character 'D", and it was the first character because in once changed the code to "Xefault workspace" ;-) and then I had an X . cbWorkspace could also have an empty title when there was no workspace loader, but there's should always be a workspace loader, now also i nthis case the title will be the default ]

- the client of the workspace : the project manager and the app (main.cpp app.cpp projectmanager.cpp) : very little change in the project manager instead of having 3 times the same code, 2 of them fall back on the third method. And on the app level no need to specify the default argument, a call without specified arguments is sufficient (also here it was inconsistent : once called without specifying it once with)

Another thing I also want to change (did no do it yet) is moving the DEFAULT_CONF (== default.workspace) from globals.h to cbWorkSpace. it is used in the cbWorkSpace (obviously) and as default argument to LoadWorkSpace method of the projectmanager. It even can be exported i think in the dll. My view : it does not belong in the globals.h, it should be a public static member of cbWorkSpace --> cbWorkSpace::DefaultConf.

That's about it for my changes.

[marfig]

Well, I did as you suggested and did a clean install on another folder, having previously removed default.workspace and default.conf. It works like a charm. I can no longer reproduce the error. 

I don't have much free time right now. But if after this, if you would still prefer a more detailed testing and some cut down version of my projects, let me know and I will provide them tonight (I'm at GMT).

[killerbot]

well good to hear now everything works. I suspect your default.conf to maybe be the guilty party.
When you have time and you feel to further investigate you are always welcome to do so. Now we don't know yet what the "real" cause is. It is always better to know ;-)
But if you don't feel like it, well no problem, major point is thing is solved also know on your system :-)