class "API_Elem_Head" has no member "typeID"

[MudratDetector]

AC27 - - WIN10 - - VS2019

.

New Year greetings to all.  I am migrating code from AC25 to AC27, and Visual Studio is giving me some pushback that I don't really understand.  I might add that I am not the original author of this code.  The working AC25 code is this:

#include <APIdefs_Elements.h>
//------------------------------------------------------
// Element driven events
//------------------------------------------------------

GSErrCode __ACENV_CALL NewElementEventHandler(const API_NotifyElementType *notifyElemType) // new element
{
	GSErrCode err = NoError;

	// Do nothing if the live audit is not enabled
	if (!JHP::LiveAudit::GetInstance().Enabled())
		return err;

	if (notifyElemType->elemHead.typeID == API_DimensionID)
	{

		if (notifyElemType->notifID == -1)
			JHP::LiveAudit::GetInstance().Observe(notifyElemType->elemHead.typeID, notifyElemType->elemHead.guid);
	}
	else
		JHP::LiveAudit::GetInstance().Observe(notifyElemType->elemHead.typeID, notifyElemType->elemHead.guid);
...

Visual Studio is telling me:  class "API_Elem_Head" has no member "typeID"

My research into this is:

Making the edit from .typeID to .type seems to work for the if condition [0], but is not happy when used in the .Observe arguments [1, 2].

Looking at the user defined LiveAudit class methods, I find

 void        Observe (API_ElemTypeID, API_Guid);

 
which surprises me, since this code is working in AC25 and GS documentation states that API_ElemTypeID has only been available since AC26.

Have I told enough of the story for someone to point me in the right direction so that I may solve this migration?
If not, let me know.

All the best,

Chris

[Viktor Kovacs]

The version is Visual Studio is actually not important. What matters is the platform toolset (141, 142, etc.). You can install earlier platform toolsets to any Visual Studio, so you can safely upgrade to Visual Studio 2022, but make sure that you have the earlier platform toolsets installed. If you are using the CMake template, it will make sure that everything is set up correctly independently from the Visual Studio version.

[MudratDetector]

Hi Viktor,

Thanks for the continued conversation on this topic.  We are architects here [and not developers] and your information has been very helpful.

I am interested in staying with VS2019 [toolset 142].  How do I get the features of the C++17 standard with toolset 142 operating in VS2019.  From what I have read, that seems possible with VS2019.  Otherwise you would not need to instruct the compiler to use the C++17 standard???

"What matters is the platform toolset (141, 142, etc.)."
VS2019 with toolset 142 is what I have installed.  It is what I would like to keep.  If I can somehow turn on, activate, or install the C++17 standard in VS2019, I would be set to continue.  I imagine [key word here - imagine] that I can do that or I would not have the need nor would I be able to instruct the compiler to use the C++17 standard.  Are these even related?

Is this even possible?

Have a great day and thanks - chris