I just tried this by adding a custom command which is:

command name: cmd /c

command parameter: echo ${PROJECT_DIR}

In the Menu->Tools->User defined tools dialog.

Then I try to create some "Empty projects" by the project wizard->select "Empty project" in different folders.

Then I try your steps but can not reproduce this bug.

Which version of C::B do you use? I'm using the latest rev9438.

If you create a couple of empty projects, then go to Build Options->Pre/PostBuildSteps and add only the line "$(PROJECT_DIR)" for each project. That will try to execute the line which amounts to nothing. Nevertheless the bug appears when doing the following:

Open one of the projects, press menu->Build.

The log seems correct here.

Then close that project, open the other project, press menu->Build.

The log is then showing that two versions of the project directory is used at the same time. One version belongs to the closed project, and the other belongs to the current project.

Such as the log, that I get with rev9446:

***

Running project pre-build steps

H:\Tmpp\tset2\test2\

Execution of 'H:\Tmpp\tset2\test2\' in 'H:\Tmpp\tset\Test' failed.

***

Notice how the log says first "\tset2\" then, "in ... \tset\" instead. The proper directory should be "\tset\" for this run. So the executed line shows the wrong directory, such as "H:\Tmpp\tset2\test2\" which belonged to the closed project.

But, if you cannot reproduce, that seems odd. I will try to erase the whole installation and install CodeBlocks again, and see if the error persists.

I did it again, here is my steps:

1, create two empty project, and add "$(PROJECT_DIR)" (no quote) in the pre-build edit control.

2, close all of them.

Open the first project, press build toolbar button:

Log:

[100.0%] Running target pre-build steps

E:\code\cb\test_code\empty1\

Execution of 'E:\code\cb\test_code\empty1\' in 'E:\code\cb\test_code\empty1' failed.

Looks good.

Then I close this project, and open another one, press the build toolbar button again:

Log:

[100.0%] Running target pre-build steps

E:\code\cb\test_code\empty2\

Execution of 'E:\code\cb\test_code\empty2\' in 'E:\code\cb\test_code\empty2' failed.

Look, it works fine, I still can't reproduce this bug.

I'm using the rev 9446 nightly build on Windows XP.

Yes, I installed all over again and the error is still there. Very strange that you cannot reproduce it still. Since it works in some cases in my computer, but not in all cases, then it is hard to believe that the error is elsewhere than in the application. The case could be if there is some kind of external call that fails on my computer, and that the update process differs depending on the case. Such as, do I have this or that setting before picking method to update the variables. Do want me to look on the code? (I dont know anything about the code, but four eyes may be more than just two eyes).

Yep, it definitely functions on your side. Hmm...

A question, where does CodeBlocks save external data? In the registry? In some config file somewhere? Maybe if I clean just everything. I think that some configs where saved since some very old version.

You run Windows XP, that is a 32-bit system, right? I run Windows 7, it is a 64-bit system. That could be the thing?

I think you can:

Write a post about this bug on C::B forum, and ask some Windows user to test for you.

You should tell the steps to reproduce this bug.

I believe there are many Win7(64bit) users.

I only have WinXP and it works fine here, so I can't have more to help you.

C::B do not use registry to store its setting, instead, it use a configure file, see the C::B wiki page to know where the configure file locates (different OSs has different locations)

One guess is that it has to do with the closing of the project. Closing a project may not clean up everything correctly on 64-bit OS.

I will do better. I am downloading the trunk from SVN now. I will build it and test if it occurs. I can set a breakpoint and find the problem (maybe).

So, compiling in 64-bit mode is not completed in trunk, yet?

Close it since it is not a bug, the usage of C::B can be discussed in forum, not here.