Recent Posts

Pages: 1 [2] 3 4 5 6 7 ... 10
Nightly builds / Re: The 09 July 2021 build (12487) is out.
« Last post by cacb on Today at 10:48:01 am »
Many thanks for the new Windows Nightly Build. I had not upgraded C::B on Windows since more than a year ago, but did now and it seems faster and better. I am looking forward to using it!

A comment/wish: I have used C::B nightly builds with the MSVC compiler for years and it works just fine. However, this approach makes it hard to create C::B plugins that run on Windows. Would it be possible to add to the description of the nightlies what exact additional downloads (with versions) are required to compile C::B plugins under Windows?  I am aware or but it seems to be out of date.
Over the next few days I am now going to test that the following compilers I have on my Windows setup work with all of the patches I have been working on and fix any bugs I come across:
I propose to add to list - looks like this site offers most fresh mingw-w64 + gcc out of msys2.
Works fine in a private firefox window, too.
The link only works when I am logged in, otherwise it redirects me to
General (but related to Code::Blocks) / Re: Welcome Newcomers - PLEASE READ!!!
« Last post by ureir on Yesterday at 12:41:43 pm »
Hello everybody !

I am new, I am here.

I am using Code::Blocks since several years in my team (starting with the 10.05 version) and now we're about to spread it in other teams of my company. I'll probably have many questions about future versions. We're using Windows "noadmin" versions.
This is not THE problem I am having as the NSIS CB installer does NOT add any file association keys. The CB exe adds the associations and if I select C/C++ it adds 12, but the NSIS uninstall code removed some of them, but not all as the "EnumRegKey" does not enumerate through all of the keys. It does not matter if I run the CB exe from the installer of after the installer has closed the keys are either way not removed. I used the NSIS 3.07 special build to log info and the keys did not appear in the output for the keys that were not deleted. I have modified the code to loop through the HKCU64 hive and then the HKCU32 hive (these were  added in NSIS 3.02 released on 23-July-2017)

My latest NSIS script is available from the following URL:

The registry removal code is currently between lines 2769 and 2826. This may change if I find any more issues in my testing, but it is looking complete apart from this one issue.
Help / Re: Windows Codeblocks uninstall - Associations left over after uninstall
« Last post by sodev on July 27, 2021, 07:27:38 pm »
@sodev The keys listed that I have a problem with are added by the CB exe and as such are in the HKCU.
And this is the problem, as regular user you can only access YOUR HKCU, but not the HKCU of OTHER users. For this you need to be root, enumerate all user accounts and check their HKCU. At least for NSIS this is not (easily) possible.
@sodev The keys listed that I have a problem with are added by the CB exe and as such are in the HKCU.

@cacb I have a "working" inno setup. It does a full install only and it is allot easier to implement the registry key removal code and after removed CCleaner does not find any registry issues (there are still fragments of CB in other registry entries that I need to check out). BTW I think I need to find a better registry checker program as searching the registry via regedit is slooowwwww.

The next step for me is to check the NSIS script registry removed code works the same way as the ISS pascal registry removal code and update it if there is any discrepancies.
Help / Re: Windows Codeblocks uninstall - Associations left over after uninstall
« Last post by cacb on July 26, 2021, 09:08:52 pm »
I have mainly some experience using InnoSetup, and then I believe this is not a problem (I have done similar with InnoSetup in the past).  "The uninstall info root key will always be HKEY_CURRENT_USER, and the "common" forms of the Shell Folder constants are mapped to the "user" forms, even if administrative privileges are available"

Probably these things are features of the installer being used. Probably NSIS is different, I'll leave it there.
Plugins development / Re: New plugin: Premake5 exporter (premake5cb)
« Last post by cacb on July 26, 2021, 08:54:43 pm »
Premake5 exporter has been updated to better accommodate generating for several build systems at once. For example, you may want to generate both linux makefiles and Visual Studio solution files at the same time, but keep them separate. The only difference when generating these files is the Premake5 action specified on the command line (the file pm5example1_premake5.lua is generated by Premake5 exporter ):

Run premake5 to generate makefiles:
m5example1$ premake5 --file=pm5example1_premake5.lua gmake2
Building configurations...
Running action 'gmake2'...
Generated build/gmake2/Makefile...
Generated build/gmake2/long/path/staticlib1/Makefile...
Generated build/gmake2/dynlib1/Makefile...
Generated build/gmake2/testconsole/Makefile...

Run premake5 to generate Visual Studio files
pm5example1$ premake5 --file=pm5example1_premake5.lua vs2019
Building configurations...
Running action 'vs2019'...
Generated build/vs2019/pm5example1.sln...
Generated build/vs2019/long/path/staticlib1/staticlib1.vcxproj...
Generated build/vs2019/dynlib1/dynlib1.vcxproj...
Generated build/vs2019/testconsole/testconsole.vcxproj...

Generating for different build systems is now better organised in separate folders under the common 'build' root.
Pages: 1 [2] 3 4 5 6 7 ... 10