Author Topic: Code::Blocks does not save settings not even 1 year later  (Read 5261 times)

Offline Brute

  • Single posting newcomer
  • *
  • Posts: 8
Code::Blocks does not save settings not even 1 year later
« on: January 19, 2015, 11:53:18 am »
After 30 failed attempts to pass the captha on registration I'm finally IN!! Jesus...

Hi,
I stopped using codeblocks 1 year ago just because my compiler setting didn't get saved.... yesterday I decided to install CB again and I've set up my toolchain settings, includes and all the stuff...

and guess what happened today when I started CB??

THIS!!



Please tell me WHAT DO I NEED TO DO IN ORDER TO HAVE MY SETTINGS SAVED?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6077
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Code::Blocks does not save settings not even 1 year later
« Reply #1 on: January 19, 2015, 01:18:25 pm »
I have meet the same issue, but this issue can be solved very easily.
You can just press the "Reset defaults" button on your screen, and then every will be OK.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks does not save settings not even 1 year later
« Reply #2 on: January 19, 2015, 04:54:49 pm »
Also, be sure not to have Code::Blocks in the Programs folder and at the same time running it in "portable" mode (that is, with a config file in the same folder).

You can have it in the Programs folder just fine, or you can use it in "portable" mode, only just not both at the same time.

Both at the same time will not work because Windows is so super intelligent and silently denies the process to write its config when it's inside a folder inside %WINDIR%/Programs. Because, you know, security is greatly increased if some file operations don't work as expected and fail without error in some more or less arbitrary locations.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Brute

  • Single posting newcomer
  • *
  • Posts: 8
Re: Code::Blocks does not save settings not even 1 year later
« Reply #3 on: January 19, 2015, 10:52:27 pm »
Thank you guys for solution, I will apply you suggestion if this problem comes back.

Offline raynebc

  • Almost regular
  • **
  • Posts: 223
Re: Code::Blocks does not save settings not even 1 year later
« Reply #4 on: January 20, 2015, 07:05:33 pm »
Also, be sure not to have Code::Blocks in the Programs folder and at the same time running it in "portable" mode (that is, with a config file in the same folder).

You can have it in the Programs folder just fine, or you can use it in "portable" mode, only just not both at the same time.

Both at the same time will not work because Windows is so super intelligent and silently denies the process to write its config when it's inside a folder inside %WINDIR%/Programs. Because, you know, security is greatly increased if some file operations don't work as expected and fail without error in some more or less arbitrary locations.
User Account Control was Microsoft's solution for most people always logging in with an Administrator level account.  Honestly I doubt there was a better way to improve peoples' security, and programs built with Windows Vista and newer in mind can properly request administrator level permission from the user whenever necessary.  The workaround for allowing non UAC-aware programs to function as they were designed is to run the program as administrator.  You can do this by right clicking on the application and selecting "Run as administrator", or you can go to the properties>compatibility for the program and set it to always run as administrator.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9723
Re: Code::Blocks does not save settings not even 1 year later
« Reply #5 on: January 20, 2015, 07:51:00 pm »
Well not to forget that C::B works perfectly fine in the programs folder as long as you don't use the portable version. However any portable software that stores it's settings in the program folder directly to be...portable does not belong into the programs folder... Just to clarify.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Code::Blocks does not save settings not even 1 year later
« Reply #6 on: January 22, 2015, 07:41:45 pm »
User Account Control was Microsoft's solution for most people always logging in with an Administrator level account.  Honestly I doubt there was a better way to improve peoples' security, and programs built with Windows Vista and newer in mind can properly request administrator level permission from the user whenever necessary.  The workaround for allowing non UAC-aware programs to function as they were designed is to run the program as administrator.  You can do this by right clicking on the application and selecting "Run as administrator", or you can go to the properties>compatibility for the program and set it to always run as administrator.
I'm sorry to be blunt, but that is some of the biggest rubbish I've heard in quite a time.

First of all, no ordinary program that doesn't do system-critical tasks should need elevated privilegues or should need to run as administrator. Nor is running as administrator a viable workaround. It is not only ill-advised but extremely obnoxious from a user perspective, too.

Second, if something fails due to lack of privilegues, it should be ovious what's happening. In particular, the OS should not be lying to you. Which is, however, just what Windows is doing. It will silently "virtualize" entire folder hierarchies or just silently let operations fail with no way of knowing for the user or the programmer.

Third, UAC is one of the most annoying, misdesigned things Microsoft ever did in order to address a design choice that Microsoft made and supported for decades. It's not like users chose to run as Administrator, it's what Microsoft taught them (prior to XP/2000 they didn't even have a choice).

The reality of UAC is that you run the custom installer of some arbitrary software (another typical Microsoft thing), and you are prompted "Do you want to allow this program to make changes to your computer?". This is the only information and the only choice that you're given, and you have no control whatsoever what this program might be doing.
Fuck, no. I do certainly not want to give this program carte blanche to making changes to my computer.

UAC with the so-called secure desktop feature (the default, but not secure in any way) means that you get a black screen for 2-3 seconds when running a program from a SMB share. Because, hey, it needs to verify signatures first (which tell nothing), in order to decide whether to show a blue or an orange alert that doesn't otherwise give any valuable information. And it reads the binary like 20 bytes at a time. Great experience.

Now you're not running as Administrator, but you are granting programs administrative rights all the time for no good reason, or you're not getting to use your computer. So you're running as administrator anyway, except now you have to click on stupid dialogs all the time.

On the other hand, you do not have any possibility whatsoever of running a program that really should run as administrator (such as e.g. Process Explorer, which does not work properly otherwise) as Administrator in a usable way.
This is simply not possible, except for running it from a shortcut and being prompted every single time. Needless to mention that doing so disables its ability to come up with an attention key sequence as well (...rendering Process Explorer useless).
Of course every single of those 10-12 useless crappy services like Adobe Updater (Adobe, Amazon, Google, Oracle, insert any name) runs with administrative privilegues all the time. Which is exactly what you really don't want.

Storing your config file inside your program's folder (and overwriting it) is harmless in almost every case. Programs for which there might be a security issue simply shouldn't do that, but for everybody else there's no real problem.
However, in order to do that, you need to elevate your process, so it is (among other things) also allowed to overwrite other binaries as well. Which is not harmless at all, and indeed a big problem.

It is nowhere near obvious where you are "officially" allowed to store your files, the locations and the means of finding them change from revision to revision. It's so complicated that virtually no developer gets it right, and you end up with a lot of shit (like 600GB of Garmin maps and 300GB of antivirus update history, and a few dozens of binaries) buried somewhere deep in your profile folder, with no way of telling what you can delete without making a program or the entire system unusable. Half of them are under "Roaming", half of them are under "Local", and some are under "Documents". Heck, I haven't even used any such feature as "Roaming" once in my life. Not few programs even write their temp files in there because the developers are confused.

Great stuff because having all that cruft on your Windows partition (and no way of moving these folders that really works without breaking everything for months ahead) means you can no longer back up your Windows partition onto a blu-ray (which would be possible otherwise).

You cannot even find your config files from within Explorer without a lot of trouble, because it hides those folders from you, so copying your config file to an USB stick or another computer is an ordeal.
« Last Edit: January 22, 2015, 07:44:26 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."