Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
Plugins development / Re: Execute plugin after saving C:B workspace?
« Last post by Miguel Gimenez on July 15, 2021, 04:05:18 pm »
You can use the tidycmt plugin as reference, it uses these two methods to show/save settings:

Code
cbConfigurationPanel* TidyCmt::GetConfigurationPanel(wxWindow* parent)
void TidyCmt::ConfigurePlugin(const TidyCmtConfig& tcc)

and a custom panel derived from cbConfigurationPanel (TidyCmtSettingsWrapper).
52
Plugins development / Re: Execute plugin after saving C:B workspace?
« Last post by cacb on July 15, 2021, 02:30:23 pm »
I have managed to get my plugin to work, more or less (a number of rough edges still).  It runs just after build (cbEVT_COMPILER_FINISHED) which is nice in many ways.  But I can now see that I have hard coded a couple of things that should be user configurable, so I have a couple of questions:

As I understand it, the "settings" for a plugin is accessed in C::B via Tools -> Plugins if the plugin has created a dialog for it in its GetConfigurationPanel() overload. Is that correct?

If I have such a dialog with settings that should persist also after closing and restarting Code::Blocks, where would I store those values? In a normal application I would perhaps use wxConfig for that, but how does this work for a Code::Blocks plugin? Is maybe the correct way to use Manager::Get()->GetConfigManager("MyPluginName") and obtain a ConfigManager* where I simply use standard primitives like Read/Write in much the same way as for wxConfig?
53
oBFusCATed, thanks for the response.  I have a working P.O.C. that optionally adds the debugger configs and links the compiler.

Over the next few days I am now going to test that the following compilers I have on my Windows setup work with all of the patches I have been working on and fix any bugs I come across:
1) GCC Cygwin
2) GCC MSYS2 - mingw32
3) GCC MSYS2 - mingw64
4) GCC TDM-32
5) GCC TDM-64
6) GCC mingw-w64
7) GCC mingw    (mingw32)
8) LLVM Clang MSYS2 - mingw64

54
Miguel, Thanks very much for the post. It helped allot.

Do you think the wiki page should include a note or text that "You can change highlighting using Settings -> Editor -> Syntax highlighting -> wxSmith generated code", so that in the future other devs don't fall into the same hole as I did?
55
Using Code::Blocks / Re: Huge problem with Code::Blocks installation
« Last post by oBFusCATed on July 15, 2021, 09:41:54 am »
Using prefix=/usr is even more dangerous, because you mess with system files. Now you've messed your original wx install... For the wx you want to develop against use a prefix in your home folder or in something like /opt...
56
General (but related to Code::Blocks) / Re: video series for getting started
« Last post by BlueHazzard on July 14, 2021, 08:12:31 pm »
There are plenty videos on youtube if you search for codeblocks
but you can generally use any c/c++ tutorial after you have seen a hello world tutorial for codeblocks
57
Using Code::Blocks / Re: Huge problem with Code::Blocks installation
« Last post by cacb on July 14, 2021, 06:21:04 pm »
How can I use a different version for my software if I'm using C::B to build it? Sorry for my ignorance, first time doing something like this.

Code::Blocks and your software are entirely independent (or should be). When you build C::B you select a wxWidgets configuration, because C::B uses wxWidgets in its implementation, but you can have more than one wxWidgets version installed. For example, here is the script I use for building C::B inder ubuntu
https://github.com/arnholm/cpde_3rdparty/blob/master/gcc/codeblocks/build_cb.sh

But I use another wxWidgets build for my own software, installed elsewhere, no problem. You just have to configure your C::B projects to reference the correct wx version for your software.  I use global variables for that, but it is not a requirement.
58
Using Code::Blocks / Re: Huge problem with Code::Blocks installation
« Last post by codeks on July 14, 2021, 05:58:10 pm »
Thank you for the replies.

1. you can have multiple versions of wx installed
2. you can use one for cb and another for your software
3. there is a flag to give the correct wx-config executable to configure... Try ./configure --help...
4. never use the default prefix of /usr/local. It is a disaster waiting to happen.

I used --prefix=/usr when configuring wxWidgets and it installed wxprec.h in /usr/include/wx-3.0/wx instead of /usr/local/ but when building codeblocks I still get:
Code
./sdk_common.h:37:10: fatal error: wx/wxprec.h: No such file or directory

I have built code using wxFreeChart for a number of years using my own project file. It works with wx3. I don't think it depends on gtk2 either, not 100% sure.

As oBFusCATed said, there is no requirement to use the same wxWidgets version for building C::B and your own software. They can be different.
wxFreeChart doesn't work with GTK3, I've tried already.

How can I use a different version for my software if I'm using C::B to build it? Sorry for my ignorance, first time doing something like this.
59
Using Code::Blocks / Re: Huge problem with Code::Blocks installation
« Last post by cacb on July 14, 2021, 05:33:03 pm »
wxFreeChart uses gtk2 so I was forced to install wxWidgets with gtk2 as well(tried both versions 2.8.12 and 3.0.5 of wxWidgets with gtk2).

I have built code using wxFreeChart for a number of years using my own project file. It works with wx3. I don't think it depends on gtk2 either, not 100% sure.

As oBFusCATed said, there is no requirement to use the same wxWidgets version for building C::B and your own software. They can be different.
60
Using Code::Blocks / Re: Huge problem with Code::Blocks installation
« Last post by oBFusCATed on July 14, 2021, 04:45:32 pm »
1. you can have multiple versions of wx installed
2. you can use one for cb and another for your software
3. there is a flag to give the correct wx-config executable to configure... Try ./configure --help...
4. never use the default prefix of /usr/local. It is a disaster waiting to happen.
Pages: 1 2 3 4 5 [6] 7 8 9 10