When using preprocessor keywords to only compile certain code blocks, I found the greyed out text does not update properly with changing the #if directive.

This can be seen by going to a tutorial, add #define COMPILE 0 at the top, then block out part of a function with #if COMPILE . At this point, everything below turns grey as expected. Adding the #endif shortly below the #if doesn't make the code below the #endif go back to normal, and causes very odd compiling errors. setting COMPILE to 1 doesn't turn the code back normal either.

I work around this by cutting the #if COMPILE line and placing at the end of the file. The text turns the proper color, then I can cut/paste it back where it belongs and it works until the next time I need to change it.

I hope I explained it well enough--pasting code doesn't reproduce it. I can make a video if you need more details.

I have experienced something similar when using:

#define identifier

#ifdef identifier
// code
#else
// code
#endif

All the enclosed code would remain greyed out regardless of the presence of the identifier or not. The compilation worked correctly though!

It seems that if it's a longer block of code between the #if and #else/#elif/#endif, then it starts to have trouble compiling(or converting to C++ to be compiled).

You have to add backslashes to each at the end of the line. A backslash as last character in a line causes this line to be joined with the next for preprocessing. For regular C++ parsing newlines are simply whitespace, so this does not matter. But preprocessor directives, in particular macro definitions end at the end of line.

Using a backslash for line continuation allows formatting long macro bodies across multiple source text lines.

#define PE_DECLARE_CLASS(class_) \
typedef class_ MyClass; \
static void setSuperClasses(); \

Dynad, I am aware of that, but that is a separate issue entirely.

But why do u want to skip large parts of code not to be compiled? If you don't need it, comment it?

Platform specific code for one thing, another is if you are developing a library and want to exclude large parts of the library from being compiled(maybe someone using it only needs 1/10th of the total library) without having to manually comment out all the code.

If you need a small part of a library, then you're using the wrong library. There are alot of libraries having similar functionality. Multiplatform is just nonsense; EE works on Windows, Android etc. Linux well good luck with that.. so im curious why u need preprocessors... cause its very ugly and bad design if you really need to.

(07-14-2013 01:41 PM)Dynad Wrote:  .. so im curious why u need preprocessors... cause its very ugly and bad design if you really need to.

I fail to see why your opinion on whether a valid C++ technique is 'ugly' or not is in any way relevant to this post.  That is your own personal opinion and preference and that's OK, you are free to code as you like.  We have chosen to use this and found some issues with it which we are reporting to the designer of the engine ... it really is as simple as that.  

Personally I prefer to use pre-compilation directives to remove code I use for inbuilt debug and development tools from my final release as it serves no useful purpose in a release build.  It may be not the only way of accomplishing the same goal but it generally works well and could not be easier to activate when it's required.  

#if DEBUG
#if OPENGL
#if MOBILE
Etc

Generally, you don't need to use #if. You can almost always use a regular if. But if I need to create strings of debug info, Memc objects to hold temp objects I am debugging, create variables for OpenGL workarounds, or maybe I want to use method A on PC and mac where there is plenty of processor power, but method B on mobile, etc, then that is a LOT of extra memory my game will be using for nothing, and oftentimes a lot of extra CPU as it does a bunch of checks each frame if (DEBUG).
I could also use comments, but why go through 10 files, looking for every instance of platform specific code, debug code, etc. when I could just change DEBUG to 0 and not compile it.
Preprocessor directives are NOT a bad design. They are a fantastic way to prevent a lot of extra work, and to make sure your code is clean and fast. Again, there are other ways to achieve the same benefits, but for me, the preprocessor is easiest and works best.

Hi,

I've just finished improving this (will be in the next release).

However please note that "#define xx" is not officially supported inside Code Editor "Code" files.

If you do need to use a custom macro, then the proper way would be to create a *.h file on the disk, make the "#define xx" in that file, and then include that *.h file in the Application properties - on the Include Headers textline.

Thanks for the improvements and the information

Thank you

(07-22-2013 08:58 PM)Esenthel Wrote:  Hi,

I've just finished improving this (will be in the next release).

However please note that "#define xx" is not officially supported inside Code Editor "Code" files.

If you do need to use a custom macro, then the proper way would be to create a *.h file on the disk, make the "#define xx" in that file, and then include that *.h file in the Application properties - on the Include Headers textline.

Esenthel,

I went ahead and followed this advice recently and it worked like a charm.
However, at some point, something changed. It seems the code editor is getting confused sometimes. I have a few scattered #if directives scattered around, and the text inside of them is grey(should be active- opening with VS shows it has the right value), and any with a call to a different namespace fail to compile(looks like it somehow breaks the files linking together, which baffles me). If I put a ! or use a constant (1) everything works fine.

Is it possible to at least get an editor generated EE_DEBUG #defined that is updated before compiling based on whether debug or release/publish is selected?

Could you attach a smallest possible project with steps included how to reproduce this issue?
Thank you very much