When debugging codeblocks, I compiled wxWidgets in debug mode (--enable-debug). To my surprise it seems that the codeblocks developers don't develop codeblocks in debug mode - there were lots of assertion violations when running it. I think that developing codeblocks _only_ with debugging enabled in wxWidgets can help to prevent some possibly serious errors (you get error messages when a function is used incorrectly, array ranges are checked and so on).

The following series of patches removes all the assertion violations from codeblocks, standard plugins and keybinder + browsetracker plugins. There are definitely more problems when using other plugins but I haven't fixed those as I don't use them (for instance I have noticed that ThreadSearch registers the same dynamic class as dragscroll). Some of the patches are only cosmetic, but some of them fix things like memory access through uninitialized value - I think it's useful to fix all the problems to see only the real problems with debug version of wxWidgets.

OK, since this patch is a kind of meta-patch, I'll continue in this meta-spirit of the patch (so no real patch here): folder_open.png and enums_folder.png have resolution 17x17. However, they are registered in wxImageList with other 16x16 images and since you have to specify the image size in wxImageList constructor, you get an assertion violation here. If there is no 16x16 version of these icons, I would suggest to change the color of vfolder_open.png, which looks the same (apart from the color) and then base enums_folder.png on this.

Just one more note - I've tested this under Linux only so it's quite possible you get some assert violations under Windows as well. Also, while I've tried to open all windows and click everything I could, it's possible that there will be some more failures under some specific situations. Anyway, I'd recommend to use wxWidgets in debug mode and when some more errors are spotted, fix them. wxWidgets pops up a cool window with backtrace which makes the debugging of the problem much easier (though it's sometimes tricky to find the real reasons of the problems).

Which images do you mean exactly? I find several images in the source base of C::B named folder_open for example.

Hi, Happy New Year!

The icons are:

src/src/resources/images/folder_open.png

src/plugins/codecompletion/resources/enums_folder.png

both 17x17 pixels and the image that could be used as their replacement after changing the color could be

src/src/resources/images/vfolder_open.png

which has correct dimensions.

It has been committed to trunk in rev 6170 by Jens. Thanks.