User forums > Nightly builds
The 21 November 2015 build (10595) is out.
raynebc:
--- Quote from: qtreez on December 01, 2015, 07:34:12 pm ---Windows 7
#1
When CB is runned with privileged rights I can't open source files by drag and drop nor by context menu.
With context menu following message box is showed:
--- Quote ---"Another instance of CB is running..."
--- End quote ---
edit:
not occuring when disable UAC.
--- End quote ---
This is a Windows limitation.
oBFusCATed:
--- Quote from: eckard_klotz on December 01, 2015, 08:17:17 pm ---As "Sagaceil" i have duplicated the compiler configuration in the compiler-settings to use a DW2 installation of the gnu compiler also. After copiing it I renamed it and changed the executables. I hope you will find some details about in the "default.conf" attached before.
--- End quote ---
Can you try to execute the same steps again and see if you can reproduce the problem?
eckard_klotz:
Hello oBFusCATed.
Sorry I tried but I failed.
* In a first step I renamed the folder CodeBlocks in my User\AppData\Roaming Folder to force C::B to create a new one.
* Than I opened C::B and copied in the settings the configuration of the GNU GCC Compiler and renamed the copy to GNU GCC Compiler DW2.
* After that I rerouted the root-folder of the compiler manually
* Finally I searched new executables, since in a DW2 installation the binaries-names end with -dw2.
Between every step I closed C::B and opened it again to check when the effect occurs. But nothing happened. Furthermore the new roaming folder contains no compilers folder animore.
It was long ago when I added the new build-suite, so it may be that an older release created the defect and since I didn't changed the compiler-options after that until now, I have not recognized what happened. But I think I have still nearly all older Nightlies. So If you know until which revision this changes result in an folder named compilers in User\AppData\Roaming I may try it out with that version.
Unfortunately after my yesterdays post I pressed the wrong button, when Windows asked me to install Win10, what means now I have no Win 8.1 animore. But after changing to Win10 the failure was still present and I renamed the file options_gcc.xml after installing Win10 to solve the problem.
To reproduce the failure I also tried some other reconfigurations of the compiler but also without reproducing the effect.
Sorry for being not helpful. But perhaps the analysis of my both files may give you a hint what kind of manipulation may be worth to try it out. In this case please tell me.
Best regards,
Eckard.
Scr3amer:
Hello guys,
I am back for some news : I might confirm some bugs I suspected one month ago.
By the way, I had this compiler flags pane bug too with Win8.1 x64 Pro and the nightly of October. I did not play with compilers with the last nightly so no bug yet.
For the bugs I suspected, it concerns CC and MinGW auto set macros. I will say bug but maybe I am wrong and I just misused the IDE.
First Bug
I use MinGW 4.9.2 x86 dw2 POSIX (the one with Qt) but these bugs happens even with other versions (like the 4.7.1 TDM) and the build I use is 10595.
When I set a project to be C++11 in build options, i check the C++11 flag in the root build options.
But when I start to write __cpluplus and use CC, it says that the value is still 199711L so the c++11 features are not present in CC.
I tried to save the project, reparse it or even close and reload the project. The bug is still here.
The only workaround I found is to close C::B and restart the whole software to have the right value 201103L, the good macros conditions and have c++11 features in CC.
Second bug
When I use predefined macros, CC does not process properly the conditions.
It says for example that __WIN32__ = 1 or __WIN32 = 1
but when I write
#ifdef __WIN32
foo();
#endif
The foo is still grayed, disabled. (of course the compilation works fine). But this time I did not find a 'good' workaround. I have to redefine the macro in custom defines tab, which is ugly :p ... And I have to close-reopen the project so that CC take in account the new defines.
Here are the screens for the C++11 issue but as you can see it is a more general bug with macro definitions, I will add screens for __WIN32 in another answer as we are limited to 2 screens per post :
Scr3amer:
The win32 bug screenshots, macros exist, have a value (which implies they are defined) but still grayed ...
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version