1
News:
The new Release 25.03 is out! You can download binaries for Windows and many major Linux distros here .
Recent Posts
2
Help / Trying to set up glad with glfw3 in Code::Blocks, beginner, please help!
« Last post by MokpotheMighty on Today at 12:14:51 am »In short: I'm a c++ beginner looking to set up GLAD with GLFW for a c++ project in Codeblocks, if someone could explain how, or tell me what I did wrong and how to fix it, or learn to fix is, please! It would mean a lot.
Just to be very clear, I'd be perfectly happy if someone could just guide me through the steps of setting up a project with glad in Codeblocks, or show me where I can find it, or how I can learn as a beginner. I'm NOT asking you to fix the code I'm showing, just showing you because the errors it gives me may tell you something about what I'm doing wrong.
I'm trying to learn how to use OpenGL programming with c++ in Codeblocks. The reason is I want to learn by doing something more exciting/creative than writing console apps over and over and learn about all the important stuff that isn't writing code into the IDE: libraries, environments etc... I started watching a Youtube tutorial https://www.youtube.com/watch?v=45MIykWJ-C4 which the first thing it tells you to do is install GLFW and GLAD. I got GLFW to work but not GLAD.
The problem is the tutorial is using VS and I'd really rather use Codeblocks.
I managed to set up GLFW for my project in Codeblocks from watching this https://www.youtube.com/watch?v=CZTEnwYgjag but I couldn't find any source clearly explaining how to do specifically set up GLAD for a project in Codeblocks.
So I tried to approximate what the person in the first video was doing in Codeblocks. I put the files that come with GLAD in the appropriate folders (I'm pretty sure) then I added the glad.c file to my project in the same folder as my main.cpp file. I admit I didn't really know what I was doing so the mistake probably happened there, but I don't even know.
The first code example in the first video (where the main function just returns 0) I got to work.
But then the second example, the one where you're supposed to conjure up a basically functioning window, the errors come... About 24 of them.
Here's the code in my main file:
#include<iostream>
using namespace std;
#include<glad/glad.h>
#include<GLFW/glfw3.h>
int main()
{
glfwInit();
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
// the first NULL in the next is to say it's NOT fullscreen
GLFWwindow* window = glfwCreateWindow(800, 800, "YoutubeOpenGL", NULL, NULL);
if (window == NULL)
{
cout << "Failed to create GLFW window" << endl;
glfwTerminate();
return -1;
}
//we actually need to tell GLFW to use this window too
// We meet with "context", an object that "holds the whole of OpenGL"
glfwMakeContextCurrent(window);
while(!glfwWindowShouldClose(window))
{
glfwPollEvents();
}
glfwDestroyWindow(window);
glfwTerminate();
return 0;
}
This gave me the errors, they all basically have this form:
||=== Build: Debug in Test_GLFW (compiler: GNU GCC MinGW64 Compiler) ===|
C:\Program Files\CodeBlocks\MinGW\bin\..\lib\gcc\x86_64-w64-mingw32\14.2.0\..\..\..\..\x86_64-w64-mingw32\bin\ld.exe: C:\Users\Mokpo\Documents\programming\cpp\GLFW\lib\libglfw3.a(win32_monitor.c.obj):win32_monitor.|| undefined reference to `__imp_CreateDCW'|||=== Build: Debug in Test_GLFW (compiler: GNU GCC MinGW64 Compiler) ===|
C:\Program Files\CodeBlocks\MinGW\bin\..\lib\gcc\x86_64-w64-mingw32\14.2.0\..\..\..\..\x86_64-w64-mingw32\bin\ld.exe: C:\Users\Mokpo\Documents\programming\cpp\GLFW\lib\libglfw3.a(win32_monitor.c.obj):win32_monitor.|| undefined reference to `__imp_CreateDCW'|
Except instead of __imp_CreateDCW, it has different variables at the end like:
__imp_GetDeviceCaps (this one appears multiple times)
__imp_DeleteDC
__imp_CreateDCW
Just to be very clear, I'd be perfectly happy if someone could just guide me through the steps of setting up a project with glad in Codeblocks, or show me where I can find it, or how I can learn as a beginner. I'm NOT asking you to fix the code I'm showing, just showing you because the errors it gives me may tell you something about what I'm doing wrong.
I'm trying to learn how to use OpenGL programming with c++ in Codeblocks. The reason is I want to learn by doing something more exciting/creative than writing console apps over and over and learn about all the important stuff that isn't writing code into the IDE: libraries, environments etc... I started watching a Youtube tutorial https://www.youtube.com/watch?v=45MIykWJ-C4 which the first thing it tells you to do is install GLFW and GLAD. I got GLFW to work but not GLAD.
The problem is the tutorial is using VS and I'd really rather use Codeblocks.
I managed to set up GLFW for my project in Codeblocks from watching this https://www.youtube.com/watch?v=CZTEnwYgjag but I couldn't find any source clearly explaining how to do specifically set up GLAD for a project in Codeblocks.
So I tried to approximate what the person in the first video was doing in Codeblocks. I put the files that come with GLAD in the appropriate folders (I'm pretty sure) then I added the glad.c file to my project in the same folder as my main.cpp file. I admit I didn't really know what I was doing so the mistake probably happened there, but I don't even know.
The first code example in the first video (where the main function just returns 0) I got to work.
But then the second example, the one where you're supposed to conjure up a basically functioning window, the errors come... About 24 of them.
Here's the code in my main file:
#include<iostream>
using namespace std;
#include<glad/glad.h>
#include<GLFW/glfw3.h>
int main()
{
glfwInit();
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
// the first NULL in the next is to say it's NOT fullscreen
GLFWwindow* window = glfwCreateWindow(800, 800, "YoutubeOpenGL", NULL, NULL);
if (window == NULL)
{
cout << "Failed to create GLFW window" << endl;
glfwTerminate();
return -1;
}
//we actually need to tell GLFW to use this window too
// We meet with "context", an object that "holds the whole of OpenGL"
glfwMakeContextCurrent(window);
while(!glfwWindowShouldClose(window))
{
glfwPollEvents();
}
glfwDestroyWindow(window);
glfwTerminate();
return 0;
}
This gave me the errors, they all basically have this form:
||=== Build: Debug in Test_GLFW (compiler: GNU GCC MinGW64 Compiler) ===|
C:\Program Files\CodeBlocks\MinGW\bin\..\lib\gcc\x86_64-w64-mingw32\14.2.0\..\..\..\..\x86_64-w64-mingw32\bin\ld.exe: C:\Users\Mokpo\Documents\programming\cpp\GLFW\lib\libglfw3.a(win32_monitor.c.obj):win32_monitor.|| undefined reference to `__imp_CreateDCW'|||=== Build: Debug in Test_GLFW (compiler: GNU GCC MinGW64 Compiler) ===|
C:\Program Files\CodeBlocks\MinGW\bin\..\lib\gcc\x86_64-w64-mingw32\14.2.0\..\..\..\..\x86_64-w64-mingw32\bin\ld.exe: C:\Users\Mokpo\Documents\programming\cpp\GLFW\lib\libglfw3.a(win32_monitor.c.obj):win32_monitor.|| undefined reference to `__imp_CreateDCW'|
Except instead of __imp_CreateDCW, it has different variables at the end like:
__imp_GetDeviceCaps (this one appears multiple times)
__imp_DeleteDC
__imp_CreateDCW
3
Help / Re: Unexpected key mapping when using C::B over X11 with Linux Trixie
« Last post by Pecan on Yesterday at 06:01:12 pm »Look at MainMenu>Settings>Editor>KeyboardShortcuts and make sure a selection that might send a carriage return has not been defined as 8 or shift-8.
The keys are also stored within file named "
.cbKeyBinder20.conf" where is where your main codeblocks.conf file resides.
The keys are also stored within file named "
.cbKeyBinder20.conf" where is where your main codeblocks.conf file resides.4
Help / Unexpected key mapping when using C::B over X11 with Linux Trixie
« Last post by ClassicRover on Yesterday at 01:36:08 pm »I have been using codeblocks successfully for several years, running codeblocks 20.something on a Raspberry Pi running Linux Bookworm. I would connect to it using ssh -Y pi@192.168.1.whatever from a big-screen Apple Mac and then launch codeblocks. The C::B windows would appear on the Mac as XQuartz windows and all would be well.
Raspberry Pi has now been upgraded to Linux Trixie, and the version of codeblocks installed by sudo apt install codeblocks is 25.03. Trixie defaults to Wayland, so the command-line I now need to use is GDK_BACKEND=x11 codeblocks &
This largely works, but one strange thing is that when I type 8 or shifted-8 (which should give me *) into a codeblocks source-code editor window, instead it is as if I had typed a carriage-return. But I do get 8 or * if I type it into e.g. the file-browser or the find dialog box. Or the xterm command prompt. Also if I type 8 or * on the numeric keypad, this does work under all circumstances. (I have not checked every key to know if there are any more funny key mappings).
Now there's a lot of things that I do this then that then the other. So I don't know if this is a problem inside codeblocks (although the fact that it behaves normally in a find window inside codeblocks might suggest so). And it might relate to my particular locale or keyboard mapping (UK English i.e. en-gb)
Are there any diagnostics I might do to e.g. find out what key-code is being received by codeblocks to tell if it is an error inside codeblocks (i.e. a bug that should be reported to you) or one that should be reported elsewhere. So far no-one on the Raspberry-Pi forum has taken it up. (They did tell me how to select X11 rather than Wayland; without which the Codeblocks windows would appear on my small R-Pi screen, not what I want).
Raspberry Pi has now been upgraded to Linux Trixie, and the version of codeblocks installed by sudo apt install codeblocks is 25.03. Trixie defaults to Wayland, so the command-line I now need to use is GDK_BACKEND=x11 codeblocks &
This largely works, but one strange thing is that when I type 8 or shifted-8 (which should give me *) into a codeblocks source-code editor window, instead it is as if I had typed a carriage-return. But I do get 8 or * if I type it into e.g. the file-browser or the find dialog box. Or the xterm command prompt. Also if I type 8 or * on the numeric keypad, this does work under all circumstances. (I have not checked every key to know if there are any more funny key mappings).
Now there's a lot of things that I do this then that then the other. So I don't know if this is a problem inside codeblocks (although the fact that it behaves normally in a find window inside codeblocks might suggest so). And it might relate to my particular locale or keyboard mapping (UK English i.e. en-gb)
Are there any diagnostics I might do to e.g. find out what key-code is being received by codeblocks to tell if it is an error inside codeblocks (i.e. a bug that should be reported to you) or one that should be reported elsewhere. So far no-one on the Raspberry-Pi forum has taken it up. (They did tell me how to select X11 rather than Wayland; without which the Codeblocks windows would appear on my small R-Pi screen, not what I want).
5
Using Code::Blocks / Re: debugger plugin's tip windows does not show content with horizontal scroll bar
« Last post by ollydbg on December 28, 2025, 11:29:30 pm »Thanks.
Al is so smart to analysis long code. It has a very large memory. I think it is at least better than me.
Al is so smart to analysis long code. It has a very large memory. I think it is at least better than me.
6
Using Code::Blocks / Re: debugger plugin's tip windows does not show content with horizontal scroll bar
« Last post by Pecan on December 28, 2025, 10:17:25 pm »Here is Gemini-CLI's evaluation of the problem.
Quote
| SearchText 'ShowValueTooltip' within src |I'll follow up on this.
| |
| Found 13 matches |
ShowValueTooltip is called from two key locations. First, sdk/ccmanager.cpp checks if a tooltip can be shown when the user hovers over a
variable. If so, a command is sent to GDB. After GDB returns the variable's value, the GDB command in plugins/debuggergdb/gdb_commands.h calls
ShowValueTooltip a second time to actually display the tooltip. The call chain starts with CodeCompletionManager, goes through the debugger
plugin, gets the value from GDB, then DebuggerManager, and finally DebugInterfaceFactory creates the tooltip window. The key call sites are
sdk/ccmanager.cpp and plugins/debuggergdb/gdb_commands.h.
[pecan prompt ]There is a problem when the debugger shows a single line value that is too long and hits the right side of the display. The bottom scroll bar
overlays the value being displayed. The window created is not tall enough to contain both the value and the bottom scroll bar. I want to know
where the window is created and why it isn't tall enough.
[Gemini response]
The value tooltip window sizing appears faulty, obscuring long text with a scrollbar. I'll investigate src/src/watchesdlg.cpp, focusing on the
ValueTooltip class, especially GridSetMinSize and UpdateSizeAndFit functions, and the usage of wxPopupWindow and wxScrolledWindow. I suspect a
height miscalculation in GridSetMinSize or an incorrect virtual size setting. My first step is to reread src/src/watchesdlg.cpp.
| ReadFile src\src\watchesdlg.cpp |
| |
After re-reading src/src/watchesdlg.cpp and analyzing the ValueTooltip class, I've pinpointed the sizing issue.
ValueTooltip Sizing Analysis
The ValueTooltip window is created in its constructor and sized primarily by the GridSetMinSize function. This function calculates the necessary
height and width for the wxPropertyGrid that displays the value.
The issue lies in how the height and width are determined, especially when a horizontal scrollbar is needed.
Height Calculation: The window's height is determined by the content of the wxPropertyGrid.
Width and Scrollbar: When the text content is too wide for the display, GridSetMinSize correctly calculates that a horizontal scrollbar is
needed and sets a virtualWidth.
The Flaw: The crucial oversight is that after deciding to add a horizontal scrollbar, the function does not increase the calculated height of
the window to accommodate the scrollbar itself.
Conclusion
Where the window is created: The ValueTooltip window is created in its constructor within src/src/watchesdlg.cpp.
Why it isn't tall enough: The sizing logic in the GridSetMinSize function in the same file fails to account for the vertical space taken up by
the horizontal scrollbar when it becomes necessary for long lines of text. The window is sized for the text only, so the scrollbar ends up
drawn on top of the last line of text.
To fix this, the code would need to be modified to add the height of a horizontal scrollbar to the total height of the ValueTooltip whenever one
is displayed.
7
Development / Re: AI may help us to create plugins
« Last post by cdavalillo on December 27, 2025, 09:31:24 am »At first option I'm against AI use, but is noticing that a wise use can be of great help. Perhaps is better if we use the AI to speed up the process of development more than to solve all our problems. I mean, use the AI to apply a consistent source code formatting, to generate useful comments in source code, to detect problematic code, to generate useful tools, etc.
Don't use AI to solve programming problems
Don't use AI to solve programming problems
8
Development / Re: AI may help us to create plugins
« Last post by stahta01 on December 25, 2025, 09:21:58 am »AI Code Generation equals AI generated copyright violations way to often for me to have peace of mind in using it.
Tim S.
Tim S.
9
Development / Re: AI may help us to create plugins
« Last post by prospero on December 25, 2025, 03:48:44 am »An explicit stance on AI (pro- or anti-) would be appreciated by users, I think. I, for one, do not want AI integration, and especially not as something I have to go out of my way to disable, and if it's going to be added, it's best kept as a plugin. If Code::Blocks goes all-in on AI the way Codelite did, I'll probably stop using it (or stick to an older version).
10
General (but related to Code::Blocks) / Re: wxWidgets 3.2.9 is out
« Last post by bouced on December 18, 2025, 09:13:39 am »wxWidgets has just published the 3.2.9 release.
For this release, wxWidgets team has built a windows binary that works directly with Codeblocks builtin compiler, one has to download the MSYS2 14.2 UCRT version.