Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
Nightly builds / Re: The 16 Januari 2022 build (12655) is out.
« Last post by Xaviou on Today at 12:41:03 pm »
Hi

I attached only the relevant part of the patch, the complete version changes m_Menu from private member to local variable and deletes it when not needed.

Thank you for testing.

BTW, there was an issue with some wxChoice not showing on toolbars on MAC (the target selection choice, for example). I made a commit fixing this on Ubuntu, can you check if it fixes the problem on MAC?

Can't build the last revision : rev 12660 broke the build process.
I've attached the output (and errors) to this post.

Regards
Xav'
2
Nightly builds / Re: The 16 Januari 2022 build (12655) is out.
« Last post by AndrewCot on Today at 12:35:13 pm »
@Miguel The SVN https://sourceforge.net/p/codeblocks/code/12666/ changes do not "delete menu;" on any of the returns between the menu create and the delete you added. More changes are required.

@ALL
I suggest creating tickets and getting the patches reviewed before being applied so the changes can be tracked and reviews done to stop code going onto the trunk that has at least been code reviewed (or had a chance of being reviewed in that if it does not get reviewed with X days then it probably should be deemed to be okay. X IMHO X should be a between 2 and 4 inclusive, but varies around Chrissy and Easter as these are usually holiday periods in large parts of the world with the other holiday periods dependent on the country).
3
Nightly builds / Re: The 16 Januari 2022 build (12655) is out.
« Last post by Miguel Gimenez on Today at 10:12:48 am »
I attached only the relevant part of the patch, the complete version changes m_Menu from private member to local variable and deletes it when not needed.

Thank you for testing.

BTW, there was an issue with some wxChoice not showing on toolbars on MAC (the target selection choice, for example). I made a commit fixing this on Ubuntu, can you check if it fixes the problem on MAC?
4
Nightly builds / Re: The 16 Januari 2022 build (12655) is out.
« Last post by Xaviou on Today at 07:29:55 am »
Hi
Can you check if this works?
Code
    for (wxMenuItemList::iterator it = m_List.begin(); it != m_List.end(); ++it)
        importSubMenu->Append(m_Menu->Remove(*it));
TIA
It does : Nice.
Don't forget to destroy the menu itself (m_Menu) because it is never done.

Thank you.

Regards
Xav'
5
Using Code::Blocks / newbie starter questions
« Last post by MrCrashTestDummy on Today at 05:00:46 am »
Hello Everyone,

I am new to C++ and CodeBlocks, and I am wondering if anyone has some starter code for a basic GUI interface?

When I learned python, I got really interested in it because I accidentally found python's tkinter gui module, and it was easy to program.  Consequently, when it comes to C++, I know if I can find a good GUI module and some basic demo scripts with all the widgets to compile, learning C++ will go much more smoothly.   

It's just with python I lucked out when I took to tkinter.  I am not sure of what is best to study for C++.  Can anyone make some good recommendations.

Also, if it helps, long term I would like to try writing vst synthesizer plugins for fruity loops.  But right now I'm just looking for a beginning "hello world" kind of GUI script to compile and start tweaking.
 
Ty!
6
Plugins development / Re: Code completion using LSP and clangd
« Last post by ollydbg on Today at 02:50:10 am »

BTW: since the console pipe is connected with clangd.exe, I'm not sure why the locker is needed. Since the content is from a thread to the main GUI thread by the Event, when you got the Event, you were already in the main GUI thread, and the content in the Event(wxThreadEvent) is already deep copied. So, I think the locker is not necessary, am I correct?

There are two non main UI threads accessing the clangd input buffer. The pipe thread and the ReadJson thread. Without the lock I assume the ReadJason thread could remove data at the same time the pipe "ProcessEvent" was writing to the (UI client.h) std::string buffer.

the "locks failed" messages could be coming from attempts to lock the symbols tree (comsuming). But it's ok. If the symbols tree update thread can't get the lock. Its ok to block.

If the lock fails in :LSP_ParseDocumentSymbols (stows symbols in tree), it just requeues itself for an idle time callback. It does not block.

Hi, Pecan. Thanks for the explanation.

I'm surprised to find that you implemented the symbol tree. This is really a good job!

7
Using Code::Blocks / Re: Using CodeBlocks to debug itself.
« Last post by AndrewCot on Today at 01:09:30 am »
I have been working on a bunch of doc updates. Have a read of the attached work in progress doc that has the info and process for using C::B to debug C::B.

It sounds like you have built C::B, but as you did not specify how, I would start at step 2 in the "To build Code::Blocks:" section as this will ensure you build C::B with all of the plugins etc.
This is my notes for how I configure the cb_release_type environment variables:
   BASE:  -g -O0 -ggdb
   Under the User Defined area add build and set it to debug

As for how C::B internally works head on over to the wiki site, https://wiki.codeblocks.org/index.php/Main_Page , and have a good read (*** some pages are way out of date, so be careful if it mentions C::B V1 I would not read it as it is way out of date).
8
Using Code::Blocks / Using CodeBlocks to debug itself.
« Last post by everSome on Today at 12:36:34 am »
Having used CodeBlocks to build a nightly debug version of CodeBlocks, how do I use CodeBlocks's debugging capabilites to Step into CodeBlocks as a way to learn about CodeBlocks internals. I'm doing this on Windows 10 using a MSYS2 environment. I've come to grips with the build process, without understanding really how to use CodeBlocks. I'm guessing this sounds rather strange, but such is life. Having CodeBlocks nightly to build itself at least works to this extent, but I haven't used the various plugins. So far I've used the mingw64 and ucrt64 compiler tool chains to build nightlies to then build themselves. I've downloaded the clang64 compiler package, but haven't tried it yet, but as it lays claim to being gcc compatible, it should/can be made to work also. To build a debug version, I set cb_release_type to -Og. Is the main code in src/src? Help! A shout out to AndrewCot and his Unofficial Code::Blocks Installers which got me up and running.
9
Plugins development / Re: Code completion using LSP and clangd
« Last post by Pecan on Yesterday at 11:49:52 pm »

BTW: since the console pipe is connected with clangd.exe, I'm not sure why the locker is needed. Since the content is from a thread to the main GUI thread by the Event, when you got the Event, you were already in the main GUI thread, and the content in the Event(wxThreadEvent) is already deep copied. So, I think the locker is not necessary, am I correct?

There are two non main UI threads accessing the clangd input buffer. The pipe thread and the ReadJson thread. Without the lock I assume the ReadJason thread could remove data at the same time the pipe "ProcessEvent" was writing to the (UI client.h) std::string buffer.

the "locks failed" messages could be coming from attempts to lock the symbols tree (comsuming). But it's ok. If the symbols tree update thread can't get the lock. Its ok to block.

If the lock fails in :LSP_ParseDocumentSymbols (stows symbols in tree), it just requeues itself for an idle time callback. It does not block. 
10
Nightly builds / Re: The 16 Januari 2022 build (12655) is out.
« Last post by Miguel Gimenez on Yesterday at 11:29:30 pm »
Can you check if this works?
Code
    for (wxMenuItemList::iterator it = m_List.begin(); it != m_List.end(); ++it)
        importSubMenu->Append(m_Menu->Remove(*it));
TIA
Pages: [1] 2 3 4 5 6 ... 10