The 27 February 2010 build (6181) is out.

[critic]

I have a question: What codepage used by `Build log` text edit component?
I have a problem with it - when I start pre/postbuild step I can't recognize output of executed binary (output is in cyrilliс codepage). I can convert output by executing `chcp` command and then execute binary in windows batch file with the same name as binary's. But to do so I need to know codepage of C::B component.


[attachment deleted by admin]

[critic]

I must report that after `global variables` dialog is closed config remains unsaved for unknown reason. And when C::B crashes all changes are loast. That's why I need after each modification of C::B config restart it.
I think it will be better to save config when dialog is closed.

The same can be made for projects and workspaces - I need save project manually every time I made changes in it (added file, removed file, changed project's config and so on).

C::B makes a show that all saved and IDE initialized after successful saving, but really it isn't.

[critic]

But if I run more than 1 instance of IDE and changed config in one of them it can be replaced by older one after closing them if it wasn't the lastest closed IDE.
To prevent this IDE can check date of last modification of config file when I select another instance of IDE and advice to apply new config or no (just the same way as for source files).

Good luck!

[Zini]

Actually the easiest solution would be to drop saving settings on application shutdown entirely and save them instead immediately when they are changed. This solves the problem of losing settings by a crash as well as any mess created by running two instances in parallel. Honestly, who came up with the idea of saving setting at shutdown time? (bet it was Microsoft )

Regarding automatic saving of projects: This was already discussed before. See here:

http://forums.codeblocks.org/index.php/topic,10653.0.html

Unfortunately it didn't lead to anything.

[oBFusCATed]

... And when C::B crashes all changes are loast....

C::B must not crash... Have you isolated and reported the crashes you experience?

[critic]

oBFusCATed, you are not right - I use nightly build (even the stable version) and it will probably crash. So the better solution in this case is to save settings when I press OK and then (if successful) to initialize IDE. In this case we can report not only stack trace, but configuration of IDE (it can be useful for developers, I think)

[ollydbg]

I have a question: What codepage used by `Build log` text edit component?
I have a problem with it - when I start pre/postbuild step I can't recognize output of executed binary (output is in cyrilliс codepage). I can convert output by executing `chcp` command and then execute binary in windows batch file with the same name as binary's. But to do so I need to know codepage of C::B component.

I also experience this kind of problem.
When I use a mingw gcc version which has Chinese language support. There are always unknown characters in the build log. The only thin I can do is : Delete the Chinese language files under C:\MinGW\share\locale
 

[oBFusCATed]

oBFusCATed, you are not right - I use nightly build (even the stable version) and it will probably crash. So the better solution in this case is to save settings when I press OK and then (if successful) to initialize IDE. In this case we can report not only stack trace, but configuration of IDE (it can be useful for developers, I think)

No, I'm right, you have not reported why it crashes.  :lol:
Developers don't need config files, most of the time, they need "steps to reproduce" (Saying "it will probably crash" doesn't help at all!)
Please start a thread, where you explain what you do to crash C::B!

Implementing the "Save on OK" feature has its drawbacks, too...

[critic]

you have not reported why it crashes.

In my message I'm not focused on some IDE crash, but on loosing of my settings each time crash happens and that is very unpleasant.

[oBFusCATed]

OK, Live with the crashes... You can't be helped  :lol:

[filofel]

OK, Live with the crashes... You can't be helped

PMJI, but that's a problem I've been experiencing too:
When C::B abruptly terminates for any reason (might not even be C::B fault), most of the time, a part of the project is lost. Or at least, the latest modifications are lost (such as files recently appened to the project, etc.).
It would be nice if anything that is saved in the config would be written to disk and flush() committed immediately, to minimize the risk of ending up with an obsolete and/or corrupted config file. I think that this is what Critic meant.

C::B crashes very rarely under me (even though I'm running bleeding edge nigthly builds, 6203 as of today, courtesy of Jens Lody's repositories, mucho thanks Jens).
But in the rare occasions when I had a problem, I ended up with missing items in my project. Even though I have Autosave set to 4 mn on both sources and project, BTW.

I guess this can be simulated quite easily by abruptly ending the C::B process. 

[MortenMacFly]

It would be nice if anything that is saved in the config would be written to disk and flush() committed immediately, to minimize the risk of ending up with an obsolete and/or corrupted config file. I think that this is what Critic meant.

Look: This would make it impossible to play with project configurations e.g. for optimisations. I personally do that quite often but if this would be saved every time I would always need to revert it back. I don't agree that this makes sense. The same would be that every time you are typing a character in the editor the editor shall be saved. This makes no sense.

The only solution I see is to adapt the autosave plugin to save project files in a certain interval, too. This can be toggled and is convenient.

I guess this can be simulated quite easily by abruptly ending the C::B process. 

Same thing here: Did you ever think when I kill a process I want exactly not to save anything?

[filofel]

<shrug>
I've been using *alot* of IDEs, and I've never experienced that kind of behavior before.
IOW, all those I know of do secure config modifications either instantly or at validation time.

The same would be that every time you are typing a character in the editor the editor shall be saved.

The comparison doesn't hold, IMO. Typical use case doesn't show the same change rate, by several orders of magnitude. And the config changes tend to be more important because they impact the whole project, and update losses are not proofed by a compiler.

Same thing here: Did you ever think when I kill a process I want exactly not to save anything?

If you consider killing C::B as a "normal" way to exit it (like a "quit without saving" menu item), then you are probably right. But as far as I'm concerned, I've never had to kill C::B (or any other IDE) for such a reason.
It looks to me the motivations you mention are more those of a developer of C::B who needs this behavior for testing C::B more conveniently than those of a vanilla user of C::B using it for developping anything else.

Nevermind...

[critic]

Please, note that: sometimes at development process I add global variables or change them and when I close `global variables` dialog I expect they will be saved at that moment, but they don't. I think this example shows that behaviour of IDE in such situations is strange.

[oBFusCATed]

<shrug>
I've been using *alot* of IDEs, and I've never experienced that kind of behavior before.

Please name some of them? Visual studio isn't doing it (all versions <=2005, don't know for newer ones).
I've not tested other IDEs in years.

If the Save on OK is implemented, what would be the behavior when there are two instances of C::B?
The second instance should detect the configuration change and then what?

To all: please keep in mind that when one software crashes this is a critical bug. It should be reported and fixed.
And developers fix crashes they know about...