User forums > Using Code::Blocks
Questions on "Gray out Inactive Preprocessor Code"
humjack:
[Skip to # list below for questions]
First and foremost, I have been using C::B as my work editor of choice for over a year now, and have recommended it to others as well. I work in embedded development, and my project includes hundreds of files and a whole mess of preprocessor definitions to support our various product versions. All I have to do is #define one of these values in an included header file, and the code completion preprocessor parser handles this beautifully project-wide.
What I find lacking is the option I am teased with called "Gray out Inactive Preprocessor Code" in the general editor settings. I've seen a few mentions of this when searching the forums, but no real response or concern following them. I'll get to it:
1) Inactive preprocessor code is straight-up black, not gray. This makes it much less obvious for those of us who use black as a default text color, thus sort of defeating the purpose of the feature.
2) The feature does not work across multiple files within a project. I have tested this with the simplest single .cpp + .hpp file project. Defining the macro in the header file will still result in code being grayed out in the .cpp file. It has to be defined specifically in the same file I am looking at.
In my opinion these issues make the feature useless in any real project scenario, and makes me wonder why it is included in a default installation of C::B... It's unfortunate because I would really benefit from it if it was a little more robust. Perhaps it could be tied into the preprocessor parsing capability of code completion. As you can guess, I have no C::B development experience so I have no idea what kind of an undertaking this would be.
Mostly I am just curious if this is on anyone's radar, as it has been this way for quite some time now. I am currently using a nightly build from a couple weeks ago.
`Zach
ollydbg:
--- Quote from: humjack on July 11, 2012, 09:43:29 pm ---my project includes hundreds of files and a whole mess of preprocessor definitions to support our various product versions. All I have to do is #define one of these values in an included header file, and the code completion preprocessor parser handles this beautifully project-wide.
--- End quote ---
The parser in our code-completion plugin does not work 100% precise compared to a normal c++/c compiler. It does not expand the #include directive as a normal C preprocessor. This means it can not know which macro is defined or not in a cpp file. So, the information from code-completion plugin can not be used for "Gray out Inactive Preprocessor Code".
To make it work, I think you can look at some developing plugins like: Semantic highlight, if you code can be compiled by clang, then I think this plugin can help to implement the "Gray out Inactive Preprocessor Code".
Jenna:
--- Quote from: ollydbg on July 12, 2012, 02:28:59 am ---
--- Quote from: humjack on July 11, 2012, 09:43:29 pm ---my project includes hundreds of files and a whole mess of preprocessor definitions to support our various product versions. All I have to do is #define one of these values in an included header file, and the code completion preprocessor parser handles this beautifully project-wide.
--- End quote ---
The parser in our code-completion plugin does not work 100% precise compared to a normal c++/c compiler. It does not expand the #include directive as a normal C preprocessor. This means it can not know which macro is defined or not in a cpp file. So, the information from code-completion plugin can not be used for "Gray out Inactive Preprocessor Code".
To make it work, I think you can look at some developing plugins like: Semantic highlight, if you code can be compiled by clang, then I think this plugin can help to implement the "Gray out Inactive Preprocessor Code".
--- End quote ---
The option in question is a scintilla option (if I remmeber correctly), based on the scintilla lexers and not a codecompletion option, so it does not know anything about other files content or global defines (e.g. from the build options).
humjack:
I'll keep an eye out for Semantic highlight (looks to still be a work in progress at the moment). I'll make sure to update this thread if I can manage to get things working the way I'd like.
Thanks for the input regarding code-competion - I was unaware of its shortcomings, it has always seemed to parse the macros properly on my projects.
`Zach
Calmarius:
Just upgraded CB to 12.11 at work. And this gray out preprocessor thing caught me off guard...
The project uses makefiles for compiling, and almost every preprocessor thing is defined in these makefiles.
Now every positive #ifdef and #if defined blocks are grayed out. I see no option to turn inactive thing off.
The only workaround so far is defining the inactive colors to be the same as the normal color.
Navigation
[0] Message Index
[#] Next page
Go to full version