Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
I have been looking at the open sourceforge tickets as there currently 496 open tickets, which is allot. A bunch of them are low hanging in that they can be closed with the following:
a)  Read the posts in the ticket and based on the post the ticket can be closed.
b) Testing with the latest nightly or recent Linux nightly versions do not exhibit the issue/bug/feature request is included in the nightly.
c) No enough info to reproduce the bug and the ticket is from 2016.
d) Bug or issue has not been seen or cannot be reproduced and the original poster has been asked to try a later version or supply more into and no response from years ago has been posted.
e) The ticket is a duplicate where I could easily find that it is a duplicate.

I have looked a at the 251 tickets so far and found the following:
- 99 Can be closed without any coding and minimal testing or reading etc a per the list above
- 28 Can be closed, but need to be looked at by one of the main CB developers to see if the ticket is okay to close.
- 94 are open
- 30 need a bit of time spent on them to see if the patch or fix in the ticket is okay or not and then get the patch applied. Some will be bad and some will be okay an others will need allot of work.

Please find in the attached (in the zip as xlsx cannot be attached) excel spread hseet the 99 that I think can be closed. I have put my comments in column C and my proposed status in column d, otherwise the data is from sourceforge (unless something has gone wrong).

Is there anyone who can take the list and run with it, so that the open sourceforge tickets can be reduced?

In the mean time I will keep looking at the rest of the tickets, but I expect that the number of easy tickets that can be closed will be less as they are more recent tickets.

Help / Re: Project - compiler changes do not cause debugger to change
« Last post by AndrewCot on Today at 02:38:52 am »
Why is there a change in main.cpp as it it to do with scripting?

The patch does fixes the problem.

Any status update on ?
Help / Re: Completion suddenly stopped working
« Last post by questionderby on Yesterday at 09:26:17 pm »
Well I'll be darned! What more can I give? Ask and I shall give the info.

I tried to reproduce it on another system (Knoppix), which didn't work, and the versions didn't match up.

On the install this happened, I press ctrl+space to complete code, and nothing for C shows up, unlike before (#include, #define, printf, for, while and such all appeared before this issue)
Help / Re: Project - compiler changes do not cause debugger to change
« Last post by oBFusCATed on Yesterday at 09:23:31 pm »
See the attached patch and let me know if it fixes it for you.
Help / Re: Completion suddenly stopped working
« Last post by oBFusCATed on Yesterday at 09:04:45 pm »
What do you mean by "doesn't work"? What doesn't work? Steps to reproduce? Can you reproduce it reliably?

You've provided four pieces of information in your post:
0. you're on x linux
1. you use 20.03
2. you've switch to dark theme
3. something you think it is called code completion doesn't work.

Given this information do you think we can help you?
Help / Completion suddenly stopped working
« Last post by questionderby on Yesterday at 08:30:16 pm »
Hi! So I'm a beginner programmer, trying to learn C, and I picked Code::Blocks for this purpose. I'm on Void Linux, using Code::Blocks 20.03

I don't really understand the IDE yet, I'm trying to learn it. So I was trying to change the GTK theme to something dark so my eyes can rest. I changed $GTK_THEME for this purpose to Yaru:dark on my shell.

GTK_THEME=Yaru:dark codeblocks

Just right after I launched codeblocks with this(and it worked btw, it was a dark theme), code completion suddenly stopped working. I looked around in the settings(editor, environment and whatnot) and couldn't find much about it. I also searched around a little on the internet, still no solutions :/

How do I go about fixing this little issue? Sorry if it's a simple thing and I wasted time on it, thanks for reading
The page references CB 13.12 for mac with the following Sourceforge link:

BUT on Sourceforge in the directory is the  following file:

So is there a CB 12.12 for the mac or not? If there is then the download page

I am not a mac user/dev and only know that a DMG file is usually a mac osx installer package/file.
Development / Re: RFC: Backticks
« Last post by ollydbg on Yesterday at 12:09:25 pm »

I recently found that msys2 has a nice tool named pkg-config, which is located in msys2_root/mingw64/bin/pkg-config.exe

Now, I see in code::blocks, it can support many libraries. For example, if you want to link opencv library.

You just have to add one line in compiler options in C::B build option

`pkg-config --cflags opencv4`

and in library options in C::B build option

`pkg-config --libs opencv4`

Really nice feature, also, I think it should also work under Linux. :)
Embedded development / Re: C::B for Microchip MCUs?
« Last post by stahta01 on Yesterday at 03:35:41 am »
FYI: The SDCC only supports a very small sub-set of Microchip MCUs.

Tim S.
Embedded development / Re: C::B for Microchip MCUs?
« Last post by AndrewCot on Yesterday at 01:55:54 am »
A google search on "codeblocks PIC compiler" returned the following pages that should help you out configuring CB with SDCC for use with PIC uControllers:

If you do not know what SDCC is then have a look at the following main SDCC page:

You can search the CB forums for "SDCC" or the compiler you want to use to see if there are details on configuring it for use with CB.
Pages: [1] 2 3 4 5 6 ... 10