CodeJock compiles just fine for us. It is downstream code that can fail to compile and that depends on the code and everything it includes.

In any case, the source I changed used "BYTE" all over the place, including the one routine that used "byte" when allocating an array. There are a number of tricks/workarounds one can try. But the number of projects we have that had the issue made it easier to just change the CJ code.

I didn't flip the CJ c++ setting to 17 to see if CJ would fail to compile.

Wouldn't this only be a problem where

using namespace std;

or

using std::byte;

is used? Or am I wrong about that?

We moved our project to C++17 recently and didn't have this problem. We compile ToolkitPro with the default language standard level.

I finally just edited the GdfiPlus.h file. The code uses "BYTE" in every place but the one that won't compile. I modified that call to allocate memory from "byte" to "BYTE" and I can compile.

CJ should probably do the same since the file uses BYTE everyone but one place just to be consistent and avoid this c++ 17 issue.

I didn't have an issue compiling the toolkit but I see it uses c++ "default" instead of c++ 17. I didn't flip that switch either to see if CJ would fail to compile as we use 17 but CJ doesn't need to in 19.2.

We have moved to vc 17 and have encountered an error:

1>y:\Codejock\Source\GraphicLibrary\GdiPlus\GdiplusPath.h(133,1): error C2872: 'byte': ambiguous symbol
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared\rpcndr.h(191,23): message : could be 'unsigned char byte'
1>C:\apps\MVS16\VC\Tools\MSVC\14.26.28801\include\cstddef(29,12): message : or       'std::byte'

I found this post regarding the issue which contains some suggestions:

I have had issues before with CJ's GdiPlus and have avoided them by adding #define _GDIPLUSPATH_H to files that encounter issues and which have nothing to do with either CodeJock or CodeJock's GdiPlus. In this case, there are so many CJ "Gdi" include files that are full of source code that I feel defining include guards is not a sustainable methodology.

CJ might want to look into changing code as per the above link to help us avoid this issue or, more desirable from my viewpoint, simply restructure GdiPlus so that the code is encapsulated in cpp files instead of include files. That should completely avoid the issue for downstream files that might need a bit of CJ in them but no GdiPlus (how many DLLs is this code being compiled into for no reason). When we want to use GdiPlus (and we do use it), we are just fine using the Microsoft implementation.