Recent Posts

Pages: [1] 2 3 4 5 6 ... 10
1
I see this issue again and again. Sometimes, the C::B just existed(crashed) without any message, this happens after when I click the "Cancel" button in the message box to continue the application. When I looked at the RPT(call stack), it just empty, so I don't have much information to share.

It is normal for crashing to happen if you click the cancel button in a wxWidgets assert style message; but it should give you a RPT file to help find the location of the crash. I have done it to track down the location where the code needs changed.

Tim S.
2
Hi,
I wrote a first unified workspace and cbp, already 4 years ago and adapted it when there was important changes in the build process of C::B (new plugins, new settings for some of them...). It's an adaptation of a previous work done by AndrewCot. It works only on Windows, just because I have not linux installed, but it should be adaptable.

Everything is available on a git (https://github.com/gerard-durand/codeblocks_gd_cbps) or a svn (https://sourceforge.net/p/codeblocks-gd-cbps/svn/HEAD/tree/) repository. See also as mentionned above https://sourceforge.net/p/codeblocks/tickets/1332/.
It uses global environment variables where you can choose the wxwidgets version, the wxWidgets 32/64 bit version, cpp_flags. The choice of 32/64 bit compiler is simply made by your general compiler setting. If you want to change something, you have only to change some global variables.
Apparently, a few guys use this build system and are happy with. Of course, as you need to set global variables, it needs some knowledge and manual setting the first time you set them. But, if you follow the "Env_vars" docs carefully, it's not so difficult.
4
Thanks, it was this timestamp thing, I was changing the date of my OS to test my program (it uses dates in some ways), some cpp files had future timestamps
5
I see the benefits from this, however, usually (at least for me) its not only the wx version that matters but also 32/64 bit and maybe a special old compiler for compatibility. For those cases it would not work unless yo very everything in the wx variable which is a bit weird. Would be great if Gerard (@gd_on) could join this conversation...

Still, it improves the situation already as it is, so I am open...
6
Development / Re: special handling of the macro replacement ""?
« Last post by Wkerry on Today at 06:57:43 am »
Any chance of moving to a commons CBP set for each environment to save allot of file and then duplication etc when a new WxWidget version comes out.
The file in https://github.com/gerard-durand/codeblocks_gd_cbps/tree/master/src look like they have solved this for windows only.
7
I see this issue again and again. Sometimes, the C::B just existed(crashed) without any message, this happens after when I click the "Cancel" button in the message box to continue the application. When I looked at the RPT(call stack), it just empty, so I don't have much information to share.
8
Any developer has some options about this topic?

I think the recent changes in the C::B should fully support this, see discussion here:

Re: special handling of the macro replacement ""?

9
Development / Re: special handling of the macro replacement ""?
« Last post by ollydbg on Today at 04:17:30 am »
10
Is the cpp file(for example, you have a a.cpp file) included in your cbp project file?
You may check the modified "timestamp" of the cpp file, because Code::Blocks use this time information to track whether the file get changed or not.
Pages: [1] 2 3 4 5 6 ... 10