User forums > Using Code::Blocks
Hiccups while typing (continuation)
ollydbg:
--- Quote from: Pecan on February 13, 2025, 11:02:15 pm ---If a parser only reads the settings at parser creation time, when the user later changes the global settings but the parser is not allowed to read them after the change, the user now is parsing without the settings he/she requested.
If that user was me, I'd call that a bug.
--- End quote ---
My initial thought is that:
When user loads a cbp, the Parser created, and the global CC option is copied to the Parser's member variable(m_Options or other names). A TempParser is created when CC plugin get initialized, this Parser serves for the standalone cpp files parsing.
When project A's CC option dialog get opened, it shows the Parser A's member variable m_Options, and when user click the Apply button, its m_Options are updated, and the global options inside .conf file also get updated.
When we switch to project B, when I open the CC option dialog, it would show:
option1: Parser B's m_Options, because m_Options in Parser B is originally a copy of .conf when it gets created, so it is before we modify the "project A's CC options".
option2: Parser B's m_Options should reread from the .conf file, so that the global CC option was copied to project B.
From your point of view, you think the "option2" is the correct option. I just think a while, and I think you are correct, that is "All the Parser instances now share a same CC options".
--- Quote ---I think it would be better to throw up a message box saying "Sorry, sniff, global settings will not be applied for a project/parser until you request a re-parse of all the other loaded projects." Just kidding...
This is a hard problem. If we don't apply changes, we violate UI standards. If we do change them, a busy parser won't apply them anyway.
Maybe we should put up a message box that says, these changes will only be applied on the next re-parse for a project.
We could list the projects that have a 'busy' not done flag.
I remember this situation from about 13 years ago. The client asked me to throw up a message box that said "Options cannot be changed while a workspace is loaded".
--- End quote ---
Yes, I agree. Changing some of the parsing option does not take effect immediately.
Even I have change the project A's CC option, and the parser A is already finished its parsing job, so to make the parser option get affect, we have to "reparse" the project.
As a convolution, I think you patch is OK! Thanks for so many times to tweak your patches.
The remaining issue is: since all the Parsers were sharing a single CC option, why do we keep so many copies? Maybe, we can just have one in the ParseManager class. :)
Pecan:
@ ollydbg
Thanks for all your help and excellent guidance.
I decided to break the changes up into two tasks.
I've committed what we have. (svn 13612) and will continue with your further suggestions.
But after I study CC some more and get more confident about your suggestions.
Thanks,
ollydbg:
OK, thanks, I have fixed an issue mentioned here: Re: The 14 June 2024 build (13529) is out.
BTW: why do you have so many custom comments in the source code, do you added manually or by some tools?
--- Code: ---// ----------------------------------------------------------------------------
void ClassBrowser::SetParser(ParserBase* parser)
// ----------------------------------------------------------------------------
--- End code ---
Pecan:
--- Quote from: ollydbg on February 17, 2025, 03:26:54 pm ---OK, thanks, I have fixed an issue mentioned here: Re: The 14 June 2024 build (13529) is out.
BTW: why do you have so many custom comments in the source code, do you added manually or by some tools?
--- Code: ---// ----------------------------------------------------------------------------
void ClassBrowser::SetParser(ParserBase* parser)
// ----------------------------------------------------------------------------
--- End code ---
--- End quote ---
They're applied by a key macro I have on my local system.
Once I can see where I'm supposed to be working, I mark it so it doesn't take so long to find it again.
Sometimes, I forget to remove the taggings.
I do it because of my eye sight. I have a terrible time seeing/differentiating code where I'm working without marking where I'm coding or debugging.
If it bothers someone, they can remove the comments or debugging tags. I'll try to do better at remembering it myself before a commit.
I forgot to do it this time because I'm working on 'stage two' of the suggested changes.
Elena:
So, since the latest NB finally came out I could test the fixes.
It *seems* there are no more hiccups, but I shall test it some longer. I will update this thread in case I still find some issue, in the meanwhile thanks for fixing !
Navigation
[0] Message Index
[*] Previous page
Go to full version