I have figured out when I have a look into to preprocessor outüut, that some code for "Loop" is generated into a wrong place.

This is from preprocessor output
#if DISPLAY_SUPPORTif (millis()>0 || millis()>1) {__VisualMicro_DEBUG_1_GLastMillis__=MicroDebug.DBG_Millis();if ( __VisualMicro_DEBUG_1_GLastMillis__<__VisualMicro_DEBUG_1_HITCOUNTER__ ){__VisualMicro_DEBUG_1_HITCOUNTER__=__VisualMicro_DEBUG_1_GLastMillis__;}if (((__VisualMicro_DEBUG_1_GLastMillis__-__VisualMicro_DEBUG_1_HITCOUNTER__)>=250)  ) { __VisualMicro_DEBUG_1_HITCOUNTER__=__VisualMicro_DEBUG_1_GLastMillis__;MicroDebug.OnBreakPointBegin(500);if (MicroDebug.outPacketStart(true)) {MicroDebug.OnBreakPointPrintBegin(1);MicroDebug.transport->print("|");MicroDebug.transport->print(millis());MicroDebug.OnBreakPointPrintEnd();MicroDebug.outPacketEnd();}MicroDebug.DBG_YieldAndWait(2);MicroDebug.OnBreakPointEnd();}}
display.Setup();
#endif


And this was the statement I have in the Setup section
#if DISPLAY_SUPPORT
     display.Setup();
#endif

When I comment out this, the the "if" with millis is generated into the loop section as expected.

Is this a Visual Micro problem or comes it from the compiler?
What could be the reason therefor?

Hi

This is debug script which is in the wrong place.

If  you switch the tool bar configuration from Debug to Release you should see a standard arduino compile without debug commands

I would like to look into the debug issue some more. Is it possible to email the .ino to the email address in the yellow box above?

Thanks

Hi

This is debug script which is in the wrong place.

If  you switch the tool bar configuration from Debug to Release you should see a standard arduino compile without debug commands

I would like to look into the debug issue some more. Is it possible to email the .ino to the email address in the yellow box above?

Thanks

Sorry, I cannot mail you the whole code, since it is thousends of lines in about 40 files.

Also, i I only comment out the compiler statements, nut leave the "display.Setup()" it works correct.

I first run into that problem when I swichted from VS 2017 to 2019. The same project did compile with 2017, but had an error in 2019. Unfortunatlly at that time I had no idea to look into the preprocessor outputs. I've tried to build up the project again from scratch with 2019, it compiled all the time. Since it is a large project, I gave up and used 2017. Then suddenly after some extension I've tried again to compile again with 2019 and it compiled. Happy about that, I worked further with 2019 until it suddenly again failed. The compiler error was "error: expected unqualified-id before 'if" and it was the Loop-line.

Now as I have had an error also with VS 2017, I've looked into the preprocessor output and figured out that problem. The error is different "error: missing binary operator before token "("" but I assume the same reason.

What I have changed in the meantime is, that before the "DISPLAY_SUPPORT" was not defined, now it is defined as "false" (I have stille several other preprocessor values which are undefined)

May be, this gives you a hint.

If you switch to Release and also switch off Project Properties (F4) > Auto generate prototypes then there should be no preprocessor changes by visual micro.

This is correct.
But that means, I cannot compile in debug mode.

Do you plan to solve the error?

This affects software debug but hardware debug will work.

We can fix it but please provide a better example of the problem using an empty or almost empty new project.

Thanks

In an (almost) empty project it did not happen, sorry.

If you would give me a hint, how it is determined, "where" to add the debig script, I can try to emprove this. I would guess, that the line with the "loop" function is somehow determined eraly and remembered. And because of some additional preprocessor oprations this line changes. And then the script is added in the wrong line.

Looking at the error again it looks like you have a stray breakpoint outside of any code?

Please open the Debug>Windows>Breakpoints and delete any breakpoints that are in an invalid location.

Does this make sense?

Yes that makes sense and also explains the different behaviour with different VS on different computers.

Didn't know, that this code comes from breakpoints.

Thx.

P.S. I could verify your hint, it was a stray breakpoint.