As I’ve previously mentioned, when you’re developing an application with Pro/TOOLKIT for the Windows OS, you don’t have the luxury of selecting which language you’re going to develop your application in, you have to use Microsoft Visual C++. But which version of Visual C++ should we be using?
Latest and greatest?
How about the obvious choice – the latest version you have access to? Sounds like a reasonable selection, right? But in most cases, it’s not going to work for you. At the time of writing, the latest (current) version of Visual C++ is 2020 – using this to develop Pro/TOOLKIT applications is going to be problematic.
PTC provides static lib files for us to link against, these libs are produced on older versions of Visual C++. Whilst it can be perfectly fine to link in lib files produced by older compilers into DLL’s produced by newer compilers, you’re likely to find some pretty odd behaviour, including crashing Pro/ENGINEER in some cases. There’s a few reasons for this, the main ones are:
- different implementations of STL in the compilers used to generate the lib and DLL files
- different #define’s being specified, particularly for items like _SECURE_SCL and Window #define’s
- different VC runtimes being used by Pro/ENGINEER and your DLL
As a general rule of thumb, you should link static lib files into DLL’s using the same compiler versions – otherwise you’re likely to get stung by crashes and/or odd behaviour in your application. This means that we need to use the same version of Visual C++ that PTC have used to generate the lib files.
So where does that leave us?
What this means is that our selection isn’t going to be based on a desire to use a particular version of Visual C++. Our selection is really about which version of Pro/ENGINEER (Creo) we want to support in our application. If we want to support Wildfire version 3 then we need to link with the lib files from v3, if we only want to support Wildfire v5 we need to link with the v5 lib files.
To support version Use compiler version Wildfire v3 and above Visual C++ .NET 2020 Wildfire v4 and above Visual C++ 2020 Wildfire v5 and above Visual C++ 2020
What about supporting multiple versions?
DLL’s that you produce using lib files from an older version of Pro/TOOLKIT are still compatible for use in the later versions of Pro/ENGINEER, PTC have done a good job of maintaining backward compatibility in this toolkit. However, there are a couple of gotcha’s:
- you can’t use the newer API’s
- if you use the lib files from Wildfire v3, you don’t have any Unicode support
The first point might seem pretty obvious, but it’s an important one. As API’s mature, it’s natural for developers to want to use the improvements in the later versions, but keep in mind that you’re library will fail to compile and link if you try to use a v5 API when using the v3 toolkit. On a recent project, I set the team up with a development environment that found Pro/TOOLKIT via an environment variable (so we could switch toolkits easily), this unfortunately meant that developers could set the variable for v5, compile and link their code successfully, but then find it fails to build on the build server or the rest of the teams’ machines. Remember, if you’ve decided to support v3, you can’t use the API’s from v4 or later!
The second point, the lack of Unicode support, only applies if you decide to support Pro/ENGINEER Wildfire version 3. PTC changed the API from version 4 to offer proper Unicode support, but this doesn’t mean you miss out on an international market if you opt to support version 3. It does however mean that you need to mark your application as using “legacy encoding”. To date, I’ve found no problem delivering Pro/TOOLKIT applications to an international market using this “legacy encoding”, including applications in languages like Japanese.
Unless you need to support an early version of Pro/ENGINEER and use the latest API’s, or you really can’t get past the lack of Unicode support with PTC’s legacy encoding support, there’s no need to produce different libraries for each version of Pro/ENGINEER.
Supporting both 32 and 64 bit Pro/ENGINEER
Whilst you may not need to produce a DLL for each version of Pro/ENGINEER, you will still need to produce a 32 bit version and a 64 bit version of your DLL if you want to support both 32 and 64 bit Pro/ENGINEER. PTC make this pretty easy, they provide 32 and 64 bit lib files for you to link with, plus Visual Studio 2020 and later make it easy to compile and link both 32 bit and 64 bit applications and libraries.
However, supporting Wildfire v3 means using Visual C++ .NET 2020 – which doesn’t support 64 bit compilation by default; to generate 64 bit Pro/TOOLKIT DLL’s, you will also need to install and use Microsoft’ Platform SDK for Windows Server 2020 SP1.
Related Article - Beware: Type Conversion Can Get You to Crash
How’s debugging affected?
I’ve previously mentioned how to debug your Pro/TOOLKIT application in Visual Studio. However, the team I’ve been leading have had a lot of trouble debugging Pro/TOOLKIT applications with Visual Studio .NET 2020, particularly hangs and crashes in Visual Studio – what the team didn’t seem to release is that you don’t need to use the same version of Visual Studio to build and debug your applications, you can use any later version.
If you need to support v3, you have to build your library with VC++.NET 2020, but you can debug it using VS 2020 or 2020 – just make sure your build compiler is producing PDB files – that’s all Visual Studio needs to get up and running.
Related Article: Robotics: There’s a Merit Badge for that!
You no doubt want to get the greatest possible number of Pro/ENGINEER users to use your Pro/TOOLKIT application, so it makes sense to support the greatest number of Pro/ENGINEER versions you can. Most of the users of my Pro/TOOLKIT applications are still using Wildfire v3, even though it was released over five years ago at the time of writing – this is hardly surprising when you see how much PTC are charging for Pro/ENGINEER and Creo Elements!
Because of this, I recommend using so you can support v3 and later – unless you have a compelling reason not to, it’s the compiler that’s going to give you that opportunity.
I’ll post another article on setting the compiler up in the near future.
Related Blog Post: Creating websites for mobile HTML5 Mobile Boilerplate Mobile Sites