Activity for Code::Blocks
-
Christo posted a comment on ticket #1574
Please do not merge this patch, please close this. I've seen a bug where sometimes jump backward stuck at same location
-
Miguel Gimenez modified ticket #1575
xyz
-
The subject says nothing useful You have stated neither your OS nor, C::B version Missing steps to reproduce Attaching the XML file would be helpful Search the forum for problems with your OS and learn how to create a proper ticket
-
Failed to configure Codeblocks (and to build) against boost-1.89.0
-
Finished with [r13760].
-
- Build: Remove boost::system detection (end of ticket #1563).
-
Wyka Strowany created ticket #1575
xyz
-
Morten MacFly committed [r13759] on SVN Repo
- avoid warnings from style checkers (no functional change)
-
BrowseTracker: When jumping back after scrolling away from a jump position, return to that exact position instead of the one before it.
-
Sergey Katunin created ticket #1573
environmentsettingsdlg: fix command for `terminology` with spaces in path
-
Fix handling $SCRIPT variable in terminal command for some cases
-
debuggergdb: kill console with child process
-
cbplugin: better validation check in ConsoleInfo
-
Elena created ticket #1569
Make Codeblocks (Windows) truly portable
-
- GUI: Do not use arithmetic operator &= with booleans.
-
- KeyBinder: Do not use arithmetic operator &= with booleans.
-
- ProjectOptionsManipulator: Do not use arithmetic operator &= with booleans.
-
For future reference: ProjectTreeDropTarget::OnData()
-
- GUI: Do not use arithmetic operator &= with booleans.
-
Dragging files to opened folders should put the files in those folders
-
Skibidi SIgma created ticket #1567
DARK MODE PLS
-
java pls
-
elshad created ticket #1565
this wizard doesn't know how to setup warning flags for this compiler
-
Code::Blocks released /Binaries/Nightlies/2025/CB_20251026_rev13754_win64.7z
-
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.
-
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:
-
* 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.
1 >
