Activity for Code::Blocks
-
Code::Blocks released /Binaries/Nightlies/2025/CB_20251026_rev13754_win64.7z
-
Miguel Gimenez modified ticket #1537
Link bug for Windows binaries zip files
-
Gerard DURAND posted a comment on ticket #1537
Yes, it has been fixed on this page some time ago after someone introduced new links on dAppCDN.com. But may be I'm blind, because I don't see how to mark this ticket as solved!
-
pecan committed [r13754] on SVN Repo
* dragscroll: version 1/4/15 251020 Remember the original (current) mouse position for other events to use.
-
* BrowseTracker: Apply JumpTracker.h assert fix (Thanks Christo and Letartare)
-
Failed to configure Codeblocks (and to build) against boost-1.89.0
-
--- a/trunk/src/plugins/contrib/NassiShneiderman/Makefile.am +++ b/trunk/src/plugins/contrib/NassiShneiderman/Makefile.am @@ -1,8 +1,6 @@ AM_CPPFLAGS = $(WX_CXXFLAGS) \ -I$(top_srcdir)/src/include \ - -I$(top_srcdir)/src/sdk/wxscintilla/include \ - $(BOOST_CPPFLAGS) \ - -DBOOST_SYSTEM_NO_DEPRECATED + -I$(top_srcdir)/src/sdk/wxscintilla/include pluginlibdir = $(pkglibdir)/plugins This line may be required by boost:spirit $(BOOST_CPPFLAGS) \ I will delete the other stuff if nobody complaints in a reasonable...
-
band-a-prend modified a comment on ticket #1563
Thanks! At r13752 Codeblocks with NassiShneiderman plugin is successsfully compiled with boost-1.89. 0. Maybe an additional NassiShneiderman autotools cleanup will be useful (see attached patch). Please note that m4/ax_boost_system.m4 is removed here too!
-
Thanks! At r13752 Codeblocks with NassiShneiderman plugin is successsfully compiled. Maybe an additional NassiShneiderman autotools cleanup will be useful (see attached patch). Please note that m4/ax_boost_system.m4 is removed here!
-
Autotools should be fixed in [r13752], can you check it? Thank you.
-
- NassiShneiderman: Remove boost_system requirement from autotools (ticket #1563).
-
ollydbg posted a comment on ticket #1564
Hi, thanks for the report, I'm not sure, but is this related to the help plugin? It is located here: src/plugins/contrib/help_plugin Any ideas?
-
Boost_system library removed from the Linux projects in [r13751]. Autotools part will come later (help with autotools is welcome).
-
- NassiShneiderman: Do not link with unused boost_system library (ticket #1563).
-
This is the patch file I used to test the Windows (wx 3.3) build of C::B. I have enabled the __WXWIN__ option. The result C::B looks OK, I don't see much difference(cpu usage) when i scroll the editor window.
-
Thanks for your work, I will test your v4 patch under my Windows system as soon as possible.
-
Enhancements in clangd-client handling of external makefile projects
-
Applied rev 13750 Thanks
-
* Clangd_client: Apply Christo patch #1559 for makefiles (Thanks christo)
-
I see in NassiShneiderman plugin sources the boost mention only in CParcer.cpp #include <boost/spirit/include/classic.hpp> #include <boost/spirit/include/classic_core.hpp> #include <boost/spirit/include/classic_symbols.hpp> #include <boost/spirit/include/classic_confix.hpp> using namespace boost::spirit::classic; and in parserules.h #include <boost/spirit/core.hpp> #include <boost/spirit/symbols/symbols.hpp> #include <boost/spirit/utility/chset.hpp> #include <boost/spirit/utility/escape_char.hpp>...
-
Tomasz Pawlak modified a comment on ticket #1560
Hi, During early testing of this patch I've tried to up-cast 'wid' in Window::InvalidateRectangle() to wxScintilla, but that caused random crashes - so I've assumed that there must some other object derived from wxWindow which also uses the generic Window class. Today I've confirmed that this is not the case - and the crashes were most likely a result of broken incremental build. So, here's v4 of the patch, which accordingly to Your requirements does not touch the core Editor class - please check...
-
Hi, During early testing of this patch I've tried to up-cast 'wid' in Window::InvalidateRectangle() to wxScintilla, but that caused random crashes - so I've assumed that there must some other object derived from wxWindow which also uses the generic Window class. Today I've confirmed that this is not the case - and the crashes were most likely a result of broken incremental build. So, here's v4 of the patch, which accordingly to Your requirements does not touch the core Editor class - pleas check...
-
Max Headroom created ticket #1564
Code::Blocks Help Menu Error
-
Looks like boost_syetem is now integrated in C++11, it should not be difficult getting rid of it in the plugin.
-
Looks like boost::syetem is now integrated in C++11, it should not be difficult getting rid of it in the plugin.
-
Looks like boost::syetem is now integratedintegrated in C++11, it should not be difficult getting rid of it in the plugin.
-
All what I expect is the those scintilla core classes should not have any wxWidgets related code, that is, it should be more general code for all platforms, and the derived classes are for any platforms, such as the wxWidgets platforms.
-
The problem is that Window::InvalidateRectangle() operates on wxWindow base class, so it can't access Editor methods/members. -> crash. I'm not fully understand this sentence. I see in your patch: @@ -106,6 +106,10 @@ Editor::Editor() { ctrlID = 0; +#ifdef SCI_DC_CACHE_ENABLED + DCcache = new devctx_cache(wxDefaultSize); +#endif + stylesValid = false; technology = SC_TECHNOLOGY_DEFAULT; scaleRGBAImage = 100.0f; I'm not sure why the DCcache variable should be put inside the Editor class, can this...
-
Apart from everything else is NassiShneiderman plugin required to be linked against boost and especially against boost_system library? Does it require headers only? The boost_system was added in https://sourceforge.net/p/codeblocks/code/11186/ and https://sourceforge.net/p/codeblocks/code/11227/ to fix Gentoo build against boost-1.65 and some later.
-
Apart from everything else is NassiShneiderman plugin required to be linked against boost and especially against boost_system library? Does it require headers only?
-
Hi, The problem is that Window::InvalidateRectangle() operates on wxWindow base class, so it can't access Editor methods/members. -> crash. Meanwhile, I've found and fixed 2 BUGs in DC cache implementation: - Disassembly dialog did not invalidated the cache (no editor events) - so it was not updated. - Incorrect handling of "abandoned" paints -> brace and occurrences highlighting did not always updated the editor. Moreover, I've changed the cache logic by introducing SCI_DC_CACHE_TRIM_ARENA - it's...
-
Failed to configure Codeblocks (and to build) against boost-1.89.0
-
Here are my comments about the patch. From my point of view, I think you should keep the scintilla's core code unchanged. So, here is my suggest: I see you have made some changes to the file: src/sdk/wxscintilla/src/scintilla/src/Editor.cxx for example: @@ -466,6 +474,7 @@ void Editor::RedrawRect(PRectangle rc) { rc.right = rcClient.right; if ((rc.bottom > rc.top) && (rc.right > rc.left)) { + SCI_DC_CACHE_INVALIDATE; wMain.InvalidateRectangle(rc); } } But I see the function wMain.InvalidateRectangle(rc);...
-
Ville Aakko created ticket #1562
Giving --help on comand line causes an ugly window with help to appear
-
Hi, For the patch to work, it really doesn't matter which location is chosen - both options will work if compiler will get correct include paths. Regarding Editor.cxx: there are 10 occurrences of SCI_DC_CACHE_INVALIDATE macro, which expands to void if the DC cache is not enabled. However, while working on this patch I've changed Editor::Redraw(): void Editor::Redraw() { //Platform::DebugPrintf("Redraw all\n"); PRectangle rcClient = GetClientRectangle(); wMain.InvalidateRectangle(rcClient); if (wMargin.GetID())...
-
Jørgen Best created ticket #1561
CodeBlocks does not start on Linux (wxSmith plugin broken)
-
Another thing I see is that it looks like the file: src/sdk/wxscintilla/src/scintilla/src/Editor.cxx is a more general file, which means every portion of the scintilla should use this file, and the platform dependent file is under the folder src/sdk/wxscintilla/src, not inside the core editor control folder src/sdk/wxscintilla/src/scintilla. My question is: can you code change be only inside the platform dependent files? Thanks.
-
Hi, thanks for the update. From my point of view, I think your added two files devcontextcache.h and devcontextcache.cpp should be put in the SDK level, Option 1: the header file should be put here: src/include and the cpp file should be put here: src/sdk Option 2: if it is only for the wxScintilla control, it should be put inside the folder: src/sdk/wxscintilla/src(for both cpp and header files). When I build C::B yesterday with your patch, I'm using the option 2, and I'm using the src/CodeBlocks_wx33_64.workspace...
-
Hi, I think the location is correct - it allows to use the cache for other widgets too (in the future). The problem is most likely with what goes to pre-compiled header or with include paths passed to GCC under MSW - I'll try to figure this out. Meanwhile, I've discovered that the cache can't be used when window size is reduced and line wrapping is enabled (I never use this option). So here's a trivial fix: Editor::ChangeSize() must call SCI_DC_CACHE_INVALIDATE if wrapping needs to be updated (otherwise...
-
Hi, I think the location is correct - it allows to use the cache for other widgets too (in the future). The problem is most likely with what goes to pre-compiled header or with include paths passed to GCC under MSW - I'll try to figure this out. Meanwhile, I've discovered that the cache can't be used when window size is reduced and line wrapping is enabled (I never use this option). So here's a trivial fix: Editor::ChangeSize() must call SCI_DC_CACHE_INVALIDATE if wrapping needs to be updated (otherwise...
-
I put the devcontextcache.h file under the folder: codeblocks_sfmirror\src\sdk\wxscintilla\include, and the cpp file is put in the folder: codeblocks_sfmirror\src\sdk\wxscintilla\src. So, the build continues.
-
-------------- Build: scintilla in Code::Blocks wx3.3.x (64 bit) (compiler: GNU GCC Compiler)--------------- [ 14.3%] g++.exe -Wall -m64 -g -pipe -mthreads -fmessage-length=0 -fexceptions -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DNOPCH -DwxUSE_UNICODE -D_WIN64 -D__WX__ -DWINVER=0x0501 -DLINK_LEXERS -DSCI_LEXER -DWXMAKINGDLL_SCI -std=gnu++11 -iquote.objs33_64\include -I.objs33_64\include -I. -IF:\code\wxWidgets-3.3.1\include -IF:\code\wxWidgets-3.3.1\lib\gcc_dll\mswu -Isdk\wxscintilla\include...
-
- Use scaled default fonts in debugger dialogs.
-
- Revert [r13747] and take into account HiDPI.
-
Yes, the 2 projects(C::B and wxWidgets) code are not synchronized for a long time. And the code enclosed with // C::B begin and // C::B end are C::B's own modification to the scintilla wxWidgets ports, for example, C::B need to handle the wxSmith code as special code folding, and those code can't be contributed to wxWidgets' port.
-
Good work, I will test it under Windows.
-
Device Context cache for Scintilla
-
-
* Increase font size in debugger windows (thanks srm2000).
-
* DragScroll 1/4/14 25/10/09 Fix using any middle mouse key combo disables context menu.
-
Federico Perini modified a comment on ticket #1558
Thank you! PS: I believe ccTimer needs renaming also above in the class typedefs: + typedef wxSafeTimer ccTimer; +#else + typedef wxTimer ccTimer; +#endif
-
Thank you!
-
- Fix variable name case in previous commit.
-
macOS: fix timer crashes in CodeCompletion plugin
-
Applied patch (adapted to code style) in [r13744], thank you.
-
* CodeCompletion: Fix timer crashes on macOS (ticket #1558, thanks Pederico Perini).
-
* SourceExporter: Replace ISO8859-1 encoding with UTF-8 when generating HTML (thanks srm2000).
-
Hi, I can see that there are already many differences between the 2 projects - in CodeBlocks sources they are eclosed between / C::B begin / and / C::B end / - so the projects are no longer synchronized.
-
Christo created ticket #1559
Enhancements in clangd-client handling of external makefile projects
-
macOS: fix timer crashes in CodeCompletion plugin
-
I do not know if this is related, as the OP did not bother giving more information, but I fixed a similar issue last week that happened when you hide the project manager window. To the OP: if you hide the project ,manager window make sure it is shown before loading a project. The latest nightly should work even with a hidden project manager.
-
macOS: fix timer crashes in CodeCompletion plugin
-
our Codeblocks forum is broken
-
I'm trying to read the v3 patch, it is a big patch, so it will take some time to understand and test.
-
do not set the PATH twice, which fix a PATH overwrite issue mentioned here:
-
Morten MacFly committed [r13741] on SVN Repo
* updated exception handler (exchndl) to v0.9.8
-
* BrowseTracker 1.4.132 2025/10/01 Apply Christo Patch (Thanks Christo)
-
OK, I think I can reproduce this bug. Thanks.
-
homertp modified a comment on ticket #1508
Steps are - in compilers dialog copy a built in compiler eg "GNU GCC Compiler" - now you have a compiler "Copy of GNU GCC Compiler" - add custom defines to "Copy of GNU GCC Compiler" - still in compilers dialog , rename "Copy of GNU GCC Compiler" to "Copy of GNU GCC CompilerR" - save everything and close the configuration window - close Codeblocks , and restart it - reopen the compilers dialog , data configuration of "Copy of GNU GCC CompilerR" are lost it still happens in codeblock 25.03 , it should...
-
Steps are - in compilers dialog copy a built in compiler eg "GNU GCC Compiler" - now you have a compiler "Copy of GNU GCC Compiler" - add custom defines to "Copy of GNU GCC Compiler" - still in compilers dialog , rename "Copy of GNU GCC Compiler" to "Copy of GNU GCC CompilerR" - save everything and close the configuration window - close Codeblocks , and restart it - reopen the compilers dialog , data configuration of "Copy of GNU GCC CompilerR" are lost it still happens in codeblock 25.03 , it should...
-
Steps are - in compilers dialog copy a built in compiler eg "GNU GCC Compiler" - now you have a compiler "Copy of GNU GCC Compiler" - add custom defines to "Copy of GNU GCC Compiler" - still in compilers dialog , rename "Copy of GNU GCC Compiler" to "Copy of GNU GCC CompilerR" - save everything and close the configuration window - close Codeblocks , and restart it - reopen the compilers dialog , data configuration of "Copy of GNU GCC CompilerR" are lost it still happens in codeblock 25.03 , it should...
-
Steps are - in compilers dialog copy a built in compiler eg "GNU GCC Compiler" - now you have a compiler "Copy of GNU GCC Compiler" - add custom defines to "Copy of GNU GCC Compiler" - still in compilers dialog , rename "Copy of GNU GCC Compiler" to "Copy of GNU GCC CompilerR" - save everything and close the configuration window - close Codeblocks , and restart it - reopen the compilers dialog , data configuration of "Copy of GNU GCC CompilerR" are lost it still happen on codeblock 25.03 , it should...
-
Steps are - in compilers dialog copy a built in compiler eg "GNU GCC Compiler" - now you have a compiler "Copy of GNU GCC Compiler" - add custom defines to "Copy of GNU GCC Compiler" - still in compilers dialog , rename "Copy of GNU GCC Compiler" to "Copy of GNU GCC CompilerR" - save everything and close the configuration window - close Codeblocks , and restart it - reopen the compilers dialog , data configuration of "Copy of GNU GCC CompilerR" are lost it still happened on codeblock 25.03 , it should...
-
-
First copy, restart C::B, second copy, restart C::B again? I just did this, and i don't see the data lost.
-
For precisions , this bug happens only on compilers that have been copied from original installed compilers in codeblocks . eg "Copy of GNU GCC Compiler" . Renaming "Copy of GNU GCC Compiler" to "Copy of GNU GCC2 Compiler" will delete all its personal configuration datas . What does this mean? I need to copy twice? First copy, restart C::B, second copy, restart C::B again? I don't know the steps.
-
Hi, thanks for the report. I just run the steps in your first post, and it looks like the renamed compiler's setting is correct after I restart the C::B, see the image shot below.
-
Compiler plugin : renaming a compiler deletes all its personal configuration datas .
-
A bit late reply. But the TDM-GCC-64 does not update for years, so can you try some other compiler suite? Such as this one: WinLibs - GCC+MinGW-w64 compiler for Windows
-
Hi, which web page? Do you mean this page: https://www.codeblocks.org/downloads/binaries/ Is this ticket reported issue get already fixed now?
-
The crash report file shows that the crash happens in the plugin code: codeblocks.exe caused an Access Violation at location 00007FF9987B2FCE in module BrowseTracker.dll Writing to location 0000000000000000. So, can you remove this dll file from the plugins folder? So that you can start C::B without this plugin.
-
Hi, how can we "reproduce" you mentioned bug? I mean can you have a step by step instructions to reproduce this issue? Thanks.
-
OK, I just search the official wxWidgets' version, and they use hashmap too. See this line: https://github.com/wxWidgets/wxWidgets/blob/9e5b420c970fe922051955f1fa1ed35216fffc1a/src/stc/ScintillaWX.h#L209 From my point of view, do you think this patch can sumit to the wxWidgets's official github? I think both of the 2 projects(codeblocks and wxWidigets) should use the same code base for maintaining reasons.
-
Hi, thanks for the patch, the code changes looks OK. I agree that using a hash table for the timers is not necessary. Our scintilla based wxWidgets code is a bit old, at least it is behind the official wxWidgets' version. But we have our own hacks. I'm not sure the official wxWidgets' version use the same timer array?
-
I have a patch to fix my reported issue, see here: Re: The library search path is not included in the PATH in the compilergcc plugin
-
Vasilii ANdonii JEgorovich posted a comment on ticket #1557
I can't use the program, but it is very necessary for my studies. Please help with this problem, I need it very urgently.
-
wxWidgets Debug Alert error in program
-
Hi, Morten, I report an issue about this change here: The library search path is not included in the PATH in the compilergcc plugin
-
* Fix assertion loading a big project with a hidden project manager.
-
Version 2 of this patch: - Fixed: Removed unused variables: ppStream::Emtx PipedProcess::m_evtline, - Fixed: ppListenerThread::Entry(): no need to set thread name after restart - CompilerGCC does not change the process index, - Fixed: PipedProcess::Launch(): no need to close strmxxx->m_fds on error, - Fixed few comments
-
- Refactor CodeBlocksApp::ParseCmdLine(), no functional changes.
-
* Use monospaced font in the command line help dialog (seen when executing codeblocks -h).
-
ScintillaWX - remove hash map for timers
-
PipedProcess for Linux patch
-
- BrowseTracker - commit missing images
-
* BrowseTracker: 1.4.131 25/09/17 Apply Christo "Jump to last modified" patch (Thanks Christo)
-
clangd_client : fix crash on completion response after project closed
-
clangd_client : fix crash on completion response after project closed
-
Applied, rev 13734, thanks Christo
-
* Clangd_client: 1.2.142 2025/09/20 Apply Christo 1554 patch and guard like use of pParser. (Thanks Christo)
1 >
