codeblocks wxWidgets 3.0 on openSuSe 13.2

[oBFusCATed]

The easiest way to give me patches is:
1. commit each change in a separate commit
2. when you have something to submit use the git format-patch command to generate the patches
3. post the patches and then I'll be able to apply them with a single command.

[oBFusCATed]

I've reproduced the issue with the menu. It is cause by the compiler's menu rebuilding. I'll see if it is a cb or wx bug.

[oBFusCATed]

I've fixed the issue in the branch. It turned out that invalid iterator is used, which is only visible in the wx-stl version.

[frithjofh]

lets try...

with an easy one.

please tell me if it worked

[frithjofh]

hi again,

had a sudden work tsunami... don't have much time right now.

attached the patch for the wxSmith

[oBFusCATed]

1. std::vector<bool> is a special beast and should be avoided, I'd prefer if this is fixed by switching the type from bool to int in the wxArray declaration
2. you're using c++11, which is not allowed at the moment

[frithjofh]

2. use of c++11 is not essential in the patches. it can easily be done without any c++11 artifact.

1. I agree on better not use std::vector<bool> for being such a strange asset. I would think it well possible to replace it with an std::vector<int> or even a plain int[] array. maybe a bitfield could be a candidate too, but that is too low level in my opinion.

in the long run I think, that wxSmith has to be gradually rewritten. it is too error prone, to hard too understand, too hard to extend, too brittle, way too low level without any need. too many language noise covers the real structure of the plugin, and the distinct parts are way too interdependent. a lot of work...

do you want me to change the patch, or have you already done that?

[frithjofh]

I forgot:

could you confirm that after the application of the patch wxSmith is working correctly?

any changes from std::vector<bool> to another and better solution could be made later on.

[oBFusCATed]

in the long run I think, that wxSmith has to be gradually rewritten. it is too error prone, to hard too understand, too hard to extend, too brittle, way too low level without any need. too many language noise covers the real structure of the plugin, and the distinct parts are way too interdependent. a lot of work...

There is no doubt about all these issues, but we need a volunteer who will spend all this time doing the work.

do you want me to change the patch, or have you already done that?

I've made it compile with a simple wxArray<int>, but I don't know if it works correctly.
If you can test this it will be the best fix for the problem.