Activity for Code::Blocks
-
T-640 posted a comment on ticket #1580
Indeed it looks like the developers have not been using Windows XP for a while, looking at the forums I see that problems started to show up at least as far as version 20, but I am glad that I can actually still make it work there to begin with, albeit with a few minor tweaks. As for the details: the 32-bit version of course, the 64-bit one is a rarity as far as I understand. The OS has the service pack 3 installed, but none of the updates after that (which probably do not matter in this context)....
-
ollydbg posted a comment on ticket #1580
Hi, thanks for the report. I'm not sure, but my guess is that no C::B devs are using Windows XP as their PC. This is a 32bit Windows version, right? So, I think it will be hard to debug such issue. If others would like to reproduce this issue, they should know which version of wxWidgets do you use, which version of C::B do you use, which compiler suite do you use to build the final C::B running on Windows XP.
-
Icons on Windows XP look odd
-
Having a further look I came to conclusion that your code should be fine, the issue is with the Dr. Mingw library. The libraries exchndl.dll and mgwhelp.dll are the ones that must have been compiled with PSAPI_VERSION 2. Furthermore, the newer version of the Microsoft's dbghelp.dll library supplied in Dr. Mingw's newer releases is incompatible with Windows XP. Not to worry, however, as there is still a more or less elegant solution. You can supply both the older Dr. Mingw version and the newest one...
-
Before trying the .qbs files in the attachment please delete the "Workspace.qbs.user" file (just the ".user" file, not the "Workspace.qbs" itself). I forgot to do it and apparently it is impossible to reupload the attachment or edit the initial message altogether. This file is something that Qt Creator makes, in some way similar to .layout and .depends files that Code::Blocks writes.
-
Build system enhancements
-
Quite an old bug, and a pretty nasty one I might add. I needed to write a build script that goes beyond simply setting compiler options, but because it gets executed multiple times, upon error being encountered, I was bombarded with a barrage of popup windows telling about the error, having to violently smash the enter key until they were all gone. What makes things worse is that there is more to it than just multiple redundant executions. I have attached an environment where the issue is reproduced....
-
Elena posted a comment on ticket #1569
Thanks T-640. Imho installing programs to C:/ is a very bad practice (despite Windows tries to force you to do so) and for a lot of reasons, in fact I install all programs in a separate D partition.
-
Quite an old bug, and a pretty nasty one I might add. I needed to write a build script that goes beyond simply setting compiler options, but because it gets executed multiple times, upon error being encountered, I was bombarded with a barrage of popup windows telling about the error, having to violently smash the enter key until they were all gone. What makes thing worse is that there is more to it than just multiple redundant executions. I have attached an environment where the issue is reproduced....
-
Quite an old bug, and a pretty nasty one I might add. I needed to write a build script that goes beyond simply setting compiler options, but because it gets executed multiple times, upon error being encountered, I was bombarded with a barrage of popup windows telling about the error, having to violently smash the enter key until they were all gone. What makes thing worse is that there is more to it than just multiple redundant executions. I have attached an environment where the issue is reproduced....
-
I second that. Except for minor things like desktop shortcuts, uninstaller entries and maybe a few other cases I prefer programs and their configuration to be fully contained within their installation folder. There is, of course, the issue of the "Program files" folder requiring administrator privileges to alter anything within, meaning Code::Blocks would have to be launched in elevated mode. But I personally keep all my installed software on a separate partition, so this is not much of a problem....
-
surrim created ticket #1578
Environment Settings: Console programs update
-
Yea, I gave his build a try, but unfortunately it has the PSAPI_VERSION set to 2 as well. The current state of affairs is indeed looking quite sour. What makes things worse is that even the virtual machine support for the older operating systems as guests is degrading, at least when it comes down to VirtualBox and VMWare. But, if the fix turns out to be as simple as setting PSAPI_VERSION back to 1, incorporating the C runtime alongside that w64devkit, it would certainly be a sight for sore eyes!...
-
Hi, good work! If you looked at this post: Re: The 06 December 2025 build (13761) is out. You can see Xaviou posted a Windows 32 bit version of C::B in every nightly build version. I'm not sure whether it works on Windows XP. It was really sad that a lot of compiler and packages were dropping the old Windows support. For example, the msys2 packages mainly drop the support for Windows7, because it is hard to maintain. See this post: Latest msys2/mingw64's gdb failed to start under Windows 7 and its...
-
Code::Blocks does not function on Windows XP
-
pecan modified ticket #1576
clangd_client : symbol browser : hang on taking symbol browser when active file out of project
-
Applied rev 13762 Thanks
-
Applied rev 13762 Thanks
-
* Clangd_client - Fix clangd_client_symbol_browser_hang_on_proxy_project. Thanks Christo.
-
BrowseTracker: When jumping back after scrolling away from a jump position, return to that exact position instead of the one before it.
-
Not applied and closed by request of creator
-
clangd_client : symbol browser : hang on taking symbol browser when active file out of project
-
I am not intentionally ignoring this patch. I'm just way behind in the ToDo list after taking care of the responsibilities of old age. :>)
-
Christo posted a comment on ticket #1576
Sorry attached wrong file previously
-
clangd_client : symbol browser : hang on taking symbol browser when active file out of project
-
Code::Blocks released /Binaries/Nightlies/2025/CB_20251206_rev13761_win64.7z
-
Miguel Gimenez committed [r13761] on SVN Repo
* Fix hang when loading a project with notes and "Auto show notes" enabled.
-
Please do not merge this patch, please close this. I've seen a bug where sometimes jump backward stuck at same location
-
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
-
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
-
-
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!
-
* 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).
-
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.
1 >
