Recent Posts

Pages: 1 2 3 4 5 6 [7] 8 9 10
61
The page does not mentoin highlighting at all, so IMHO if you want to say that you should first say something like "The whole block is hilghlighted differently to remark it must not be modified. You can change...".
62
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).
63
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?
64
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

65
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?
66
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...
67
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
68
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.
69
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.
70
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.
Pages: 1 2 3 4 5 6 [7] 8 9 10