Debugged a while, I found the reason why this bug happens, but I don't have a clean way to fix this issue.
See, the CC setting was stored in configure file.
When C::B start up, CC will create a default parser object called "temp parser".
When a parser object is created, it will copy the settings(such as the "Case sensitive matches") from the configure file to its own member variable.
When you open the CC dialog, the active parser object's setting will be modified also the CC related setting in configure files will get updated. This means, the configure file contains the active parser's settings.
When a CB project loaded, a new parser object(we call "new parser" here) is created and activated. So far, so good. When you changed the CC setting, both the "new parser"'s setting and the configure file get updated.
The issue comes when you close C::B, which means, you need to
1, destroy "new parser"
2, destroy "temp parser"
When destroy "new parser", all its setting was saved, but after that, the active parser switches to "temp parser", the setting in "temp parser" was active, and finally the "temp parser" get destroyed, its setting was saved (not the "new parser"), so your setting was lost!
I have not a good idea to fix this issue. Say, we have a setting shared by several parser objects. But they may be different, but the last destroyed parser's setting will be saved to the configure file.
Any plans to fix this issue? If not please say so, so I can take a look at it ... it is quite annoying...
I know it's annoying. As a workaround, you can just open C::B (without any project opened), and open the setting dialog for CodeCompletion, then close C::B, all the settings should be saved.
If you do want to forbid the setting saving of the "temp parser", you can just add an parameter of the Parser's constructor, say
Parser::Parser(....., bool saveSetting = true)
{
...
}
And create a temp parser in the code
m_TempParser = new Parser(this, nullptr, false); // the last parameter means we don't want to save the setting of this temp parser
But note that this still break something, such as the workaround I said before.
