I think I'm having similar issues with code targeted at Teensy 3.5 - intellisense doesn't like any ENUM definitions/references, and also some function definitions.  I just updated my install to 2.2022.1128-4, but that did not seem to help.

I created a new Arduino project targeted at T3.5 as shown below

/*
    Name:       IntellisenseTest.ino
    Created:	12/10/2022 11:58:21 AM
    Author:     FRANKNEWXPS15\Frank
*/

enum AnomalyCode
{
  NO_ANOMALIES = 0,
  STUCK_AHEAD,
  STUCK_BEHIND,
  OBSTACLE_AHEAD,
  WALL_OFFSET_DIST_AHEAD,
  OBSTACLE_BEHIND,
  OPEN_CORNER,
  DEAD_BATTERY,
  //CHG_STN_AVAIL, //added 04/14/22 c/o 06/12/22  back in 06/14/22 c/o again 06/16/22
  CHARGER_CONNECTED //added 05/22/22
};

AnomalyCode errcode = STUCK_BEHIND;
AnomalyCode errcode2 = (AnomalyCode)STUCK_BEHIND;
AnomalyCode errcode3 = AnomalyCode::STUCK_BEHIND;

void setup()
{


}

void loop()
{


}
 

Here's a screenshot of my current robot program showing a number of 'errors' highlighted by intellisense, even thought the program runs and compiles correctly (clicking on the link doesn't work for me, but copy/pasting it into a browser window does - don't know why)

https://drive.google.com/file/d/1j9XLtrC8CoTTNPpXagRuPaqRH-IQmk9z/viewusp=share_...

Looking through the 'New Releases' post, I am more than a little confused about all the different versions. It appears that 2.2022.1128-4 is the latest version, but it doesn't seem to affect the problem, even with a brand-new project.

What am I missing here?

TIA,

Frank

There is a free upgrade to the new version of Visual Micro. It provies a new intellisense engine that understands Gcc better than the older Vs C++ that Visual Micro used.

The older projects are still supported in the new release and we will be releasing an auto update feature. 

In the meantime, close the solution, make a copy of your .vcxproj file, then delete it. After that use "File>Open>Arduino Project" to open the master INO file. That will create you a new .vcxproj that uses the new format. After that you can re-open the original solution.

Let us know how it goes or any questions.

ps: In 2.0, you should fine intellise is very accurate now and fully understands the gcc language. There should be no need to refine any code. fyi: in all versions of visual studio, we can add a vs-intellisense.hints file to a project.

cfeied wrote on Dec 10^th, 2022 at 9:47pm:



This DID help - just not as completely as I hoped.  Using the typedef trick removes the intellisense errors from all references to enums, EXCEPT it still flags functions with enum return types, such as:

AnomalyCode CheckForAnomalies()
{
  AnomalyCode errcode = NO_ANOMALIES;

  if (gl_bStuckAhead)
  {
    errcode = STUCK_AHEAD;
  }
  else if (gl_bStuckBehind)
  {
    errcode = STUCK_BEHIND;
  }
  else if (gl_bObstacleAhead)
  {
    errcode = OBSTACLE_AHEAD;
  }
  else if (gl_bWallOffsetDist)
  {
    errcode = WALL_OFFSET_DIST_AHEAD;
  }
  else if (gl_bObstacleBehind)
  {
    errcode = OBSTACLE_BEHIND;
  }
  else if (gl_bDeadBattery)
  {
    errcode = DEAD_BATTERY;
  }
  //06/12/22 removed, 06/14/22 replaced, 06/16/22 removed again
  //else if (gl_bIRBeamAvail)
  //{
  //  errcode = CHG_STN_AVAIL;
  //}
  else if (gl_bChgConnect)
  {
    errcode = CHARGER_CONNECTED;
  }
  else
  {
    errcode = NO_ANOMALIES;
  }

  //gl_pSerPort->printf("at bottom of  CheckForAnomalies() with errcode = %d\n", errcode);
  return errcode;
} 

In the above function, the function name is underlined with a red squiggly line, but the line 'AnomalyCode errcode = NO_ANOMALIES' isn't anymore (after the 'typedef' trick was applied).  Also, any call to the CheckForAnomalies() function is underlined as well.

FrankP wrote on Dec 11^th, 2022 at 8:07pm:


There are workarounds for all of it, but since you're writing something at least moderately complex you can make the whole problem go away if you just move your enum definition out of the ino file. This class of problem and its workarounds are much worse when you allow the preprocessor to perform arduino-style automatic creation of header declarations from the ino file(s).

I get no squiggles when I just go back to a plain old enum defined in an enums.h file (with no associated .cpp file).  Of course we need to #include "enums.h" at the top of the .ino file (VisualMicro does that automatically if you let it create the arduino-style code file for you). 

I'll attach two screenshots showing (1) the enum file and (2) all of your code in an ino file, with no red squiggles anywhere.

This is on version  1.2022.0905-4. In my experience, VM intellisense can understand enums just fine even without the recent improvements based on gcc-awareness.

In fact, for many years I have never allowed a red squiggle in VM to persist, with the sole exception of an unusual macro construction used by Paul Stoffregen for his audio library.  

---

// enums.h

#ifndef _ENUMS_h
#define _ENUMS_h

#if defined(ARDUINO) && ARDUINO >= 100
	#include "arduino.h"
#else
	#include "WProgram.h"
#endif

enum AnomalyCode
{
    NO_ANOMALIES,
    STUCK_AHEAD,
    STUCK_BEHIND,
    OBSTACLE_AHEAD,
    WALL_OFFSET_DIST_AHEAD,
    OBSTACLE_BEHIND,
    OPEN_CORNER,
    DEAD_BATTERY,
    //CHG_STN_AVAIL, //added 04/14/22 c/o 06/12/22  back in 06/14/22 c/o again 06/16/22
    CHARGER_CONNECTED //added 05/22/22
};
#endif

 

/*
    Name:       EnumTest.ino
    Created:	12/10/2022 4:00:10 PM
    Author:     CFF-ANTHEA\cff
*/

#include "enums.h"

AnomalyCode errcode = STUCK_BEHIND;
AnomalyCode errcode2 = (AnomalyCode)STUCK_BEHIND;
AnomalyCode errcode3 = AnomalyCode::STUCK_BEHIND;

bool gl_bStuckAhead = false;
bool gl_bStuckBehind = false;
bool gl_bObstacleAhead = false;
bool gl_bObstacleBehind = false;
bool gl_bWallOffsetDist = false;
bool gl_bChgConnect = false;
bool gl_bDeadBattery = false;

AnomalyCode CheckForAnomalies()
{
    AnomalyCode errcode = NO_ANOMALIES;

    if (gl_bStuckAhead)
    {
        errcode = STUCK_AHEAD;
    }
    else if (gl_bStuckBehind)
    {
        errcode = STUCK_BEHIND;
    }
    else if (gl_bObstacleAhead)
    {
        errcode = OBSTACLE_AHEAD;
    }
    else if (gl_bWallOffsetDist)
    {
        errcode = WALL_OFFSET_DIST_AHEAD;
    }
    else if (gl_bObstacleBehind)
    {
        errcode = OBSTACLE_BEHIND;
    }
    else if (gl_bDeadBattery)
    {
        errcode = DEAD_BATTERY;
    }
    //06/12/22 removed, 06/14/22 replaced, 06/16/22 removed again
    //else if (gl_bIRBeamAvail)
    //{
    //  errcode = CHG_STN_AVAIL;
    //}
    else if (gl_bChgConnect)
    {
        errcode = CHARGER_CONNECTED;
    }
    else
    {
        errcode = NO_ANOMALIES;
    }
    //gl_pSerPort->printf("at bottom of  CheckForAnomalies() with errcode = %d\n", errcode);
    return errcode;
}
void setup()
{}
void loop()
{}
 

Tim@Visual Micro wrote on Dec 12^th, 2022 at 1:28am:


Ditto for me - thanks for the explanation!

Frank

cfeied wrote on Dec 12^th, 2022 at 1:20am:


How do you handle the "identifier 'uint32_t' is undefined problem.  I can change them all to 'unsigned long', but I hate to change out a more specific identifier with a more vague one.

Any updates on the VM/Intellisense issue?  I put all my enums into a 'enums.h' file, but I'm still getting lots of red bars up and down my code window.

Tim@Visual Micro wrote on Dec 16^th, 2022 at 1:53pm:


I think you are correct.  I went back and *carefully* went through my IntellisenseTest.ino project and was able to get it to compile 'squiggle-free' using @cfeied's 'enums.h' trick.

Then I went back and did the same thing with a slightly larger 'real' program (a part-task test program for my robot) and got it to compile 'squiggle-free' using the same 'enums.h' file.  During this process I discovered that the 'enums.h' file I had been using on the part-task program was missing some enum sections, and that was what was causing my 'issues'.

Then I went back to one of my full-length robot programs that exhibited *lots* of red intellisense errors, and started copying some of the problematic code over to my new 'IntellesenseTest.ino' program and was able to get it to compile 'squiggle-free' as well.

Then I checked my full-length program to see if it said 'Arduino' on the project line and it does not, so I suspect that is the difference somehow.   

So, the next question is - what do I need to do to convert my 'non-Arduino' programs to the newer style so I can finally get rid of all the red marks that are driving me crazy! 

Frank

Tim@Visual Micro wrote on Dec 17^th, 2022 at 4:29pm:


Works great!  YAY!!   

Thanks - I can FINALLY get some rest from my OCD angst when seeing all those red marks 

I was looking at your code for another reason ealier and realised it might help to point out a quirk of arduino. 

You can use enums in your .ino files but you have to be concious of the order you define things in the code.

At compile time, Visual Micro and the Arduino IDE automatically add any missing prototypes. This means that an enum can be defined and used in any place in the .ino code. The prototypes are added to the top of the code before the first user type, if there are no user types then before the first method.

When working from an intellisense perspective we don't have those prototypes (it's something we might try to look into). This means that you will see intellisense errors unless you use a .h file or unless you write your code in one of the two following ways.

//1) Add the prototype yourself. Note the passEnum() prototype at the top of the code has exact same signature as the method with ; suffix.
//

void passEnum(VL53L0X_REQUEST e, uint32_t b);

enum VL53L0X_REQUEST
{
	VL53L0X_READYCHECK, //added 11/10/20 to prevent bad reads during Teensy setup()
	VL53L0X_CENTERS_ONLY,
	VL53L0X_RIGHT,
	VL53L0X_LEFT,
	VL53L0X_ALL, //added 08/06/20, replaced VL53L0X_BOTH 10/31/20
	VL53L0X_REAR_ONLY //added 10/24/20
};

void passEnum(VL53L0X_REQUEST e, uint32_t b)
{

}

void setup()
{
    uint32_t a = 0;

    passEnum(VL53L0X_ALL, a);
}

void loop()
{ }

 

// 2) define the .ino code in the correct order so that a prototype is not needed. Note that the method passEnum() is first and the enum defined after that. To be honest I would have the expected the types to be created before they are used but I guess an enum i different.
//

void passEnum(VL53L0X_REQUEST e, uint32_t b)
{

}

enum VL53L0X_REQUEST
{
	VL53L0X_READYCHECK, //added 11/10/20 to prevent bad reads during Teensy setup()
	VL53L0X_CENTERS_ONLY,
	VL53L0X_RIGHT,
	VL53L0X_LEFT,
	VL53L0X_ALL, //added 08/06/20, replaced VL53L0X_BOTH 10/31/20
	VL53L0X_REAR_ONLY //added 10/24/20
};

void setup()
{
    uint32_t a = 0;

    passEnum(VL53L0X_ALL, a);
}

void loop()
{ }