Creo Toolkit (C) vs Creo Object Toolkit (C++)

[lhoogeveen]

Are people using Object Toolkit (C++)? We have several Creo custom utilities written with Toolkit (C), but I was curious if other developers have switched to using Object Toolkit (C++) when possible.

Here's my current understanding of the 2 APIs:

Toolkit (C) Pros:

• The API wizard HTML is great (<creo_loadpoint>\Common Files\protoolkit\protkdoc\index.html)
  • Ability to search for API commands and to click on hyperlinks for more information.
  • Easy to find example code on many of the older APIs (sadly many of the newer Toolkit (C) APIs don’t have example code).
• I believe Toolkit (C) has more API commands than Object Toolkit (C++).
• Can still use C++ code with the Toolkit (C) code.

Toolkit (C) Cons:

• Strings are overcomplicated. (char vs wchar_t, ProLine, ProName, ProMdlName, etc.).
  • If PTC changes the length of a string (ex: ProName (32) to ProMdlName (180)) then you may have to make updates your code.
• Memory management – need to allocate and free memory. Can lead to application crashing if done wrong.
• Not object based which can lead to more verbose code. Example:

  • ProMdl pro_mdl;
    pro_error = ProMdlCurrentGet(&pro_mdl);
    ProMdlName pro_ wszMdlName;
    pro_error = ProMdlMdlnameGet(pro_mdl, pro_wszMdlName);

• Error handling is done using ProError vs more modern Try Catch. (ProError isn’t bad once you get used to it.)

Object Toolkit (C++) Pros:

• Object based - getting additional attributes or commands is easier. Example:

  • xstring wCurrentModelName = wSession->GetCurrentModel()->GetFileName();

• Error handling with Try Catch
  • Hopefully easier to prevent applications from crashing
• Strings should be easier since API’s use xstring and xrstring.

Object Toolkit (C++) Potential Cons:

• Not all Toolkit (C) commands are have an equivalent in Object Toolkit (C++)?
  • For example: I don’t see Object Toolkit (C++) equivalents for Toolkit (C)  ProAsmcompEmbed, ProMdlIsEmbeddedName, ProMdlIsEmbeddedName. This would likely mean you have to mix Toolkit (C) and Object Toolkit (C++) commands.
• Where to search/find example code?
  • Creo 11’s new online API wizard seems promising but still doesn’t appear to have example code mixed in. https://support.ptc.com/help/creo_toolkit/otk_cpp_pma/r11.0/usascii/
  •  <creo_loadpoint>\Common Files\otk_cpp_doc\objecttoolkit_Creo\index.html does not have example code that I see.
  • It’s tedious to search through all the files in “Common Files\otk\otk_cpp”. Fortunately, Notepad++ allows you to search multiple files.
• Licensing concerns?
  • It looks like if you have a Toolkit developer license you also get an Object Toolkit developer license. https://www.ptc.com/en/support/article/CS125183
  • I’m not aware of there being a Runtime license for Object Toolkit (C++) (aka a license for each user of the custom application). I found this article for Object Toolkit Java but nothing on Object Toolkit (C++) - https://www.ptc.com/en/support/article/CS190307. I would definitely not use it if there was a runtime license.
• There’s still no C#/.net API for Creo. This would be my preferred language for an API since Creo only runs on Windows.

Seems like PTC still gives primary support to Toolkit (C). If primary would be Object Toolkit (C++) (not having to revert to Toolkit and easier to find code examples), then switching to Object Toolkit would have very few cons other than investing the time to convert/test. This could happen slowly since Toolkit and Object Toolkit commands can be mixed.

[JB_87049]

I prefer ProToolkit as I prefer C.
I would love to see a Creo version that runs on Linux. The last version that did ran was WildFire 3.

[HannesBuxbaum]

PTC develops both TOOLKIT (C, TK) and Object TOOLKIT (C++, OTK).
"Creo TOOLKIT is the primary PTC application programmer's interface (API) for Creo Parametric" (Creo 11 tkuse.pdf)
I can overview only fractions of both APIs, but it seems to me in general TK > OTK regarding to functionality.
The release notes (Common Files/protoolkit/Creo_Toolkit_RelNotes.pdf, Common Files\otk_cpp_doc\Otk_Cxx_RelNotes.pdf) give an impression on the constant API growth, see "New Functions" and "Superseded Functions".

TK and OTK both come with an API Wizard (lookup functions/classes) and user guides (wider description of concepts/context).
The user guides complement each other: you should consult both, when in doubt or not found what you needed.
Common Files\protoolkit\tkuse.pdf
Common Files\otk_cpp_doc\otkug.pdf

Code examples:
The PTC shipped examples are a good reference for more than just getting started.
I use a search tool for content searching in all *.c;*.cpp;*.cxx (or even header) files in "Common Files\protoolkit", "Common Files\otk" and "Common Files\otk_cpp_doc" (recursivly).

License:
The article you mentioned makes it clear: CS190307 "Creo Object TOOLKIT Java license requirement".
There is a TK/OTK (one for both) developer license (for unlocking TK/OTK applications).
There are separate licenses for advanced licensed features like TOOLKIT-for-3D_Drawings, TOOLKIT-for-Mechanica, TOOLKIT-for-Access_Solvers and TOOLKIT-for-Advanced_NC).
There is no runtime license.
See also: "When is a TOOLKIT license required for the developer in Creo Parametric?" https://www.ptc.com/en/support/article/CS60620

"There’s still no C#/.net API for Creo."
True, except invoking the VB/VBA (COM) API. Technically, you can start CLR code from within C++ (EXE/DLL), but the CLR code cannot simply call the TK/OTK API (although the C++ part can).
(I did it once, creating a .NET window from within a synchronous OTK application. The CLR code does not "see" the TK/OTK functions in the included TK/OTK libs. If this could be made visible to the CLR code, one could call TK/OTK functions.)

I agree to the pros and cons you listed.
Sadly, the string handling (xstring/xrstring) is still far from Java/.NET string comfort (especially if you have to care about Unicode in/output).
The fewer error handling and automatic memory management are good reasons to switch to C++/OTK (even if it is step by step in existing projects by adding C++ modules with C interfaces).
As you said, missing OTK functionality is not a problem since we can call TK C functions.

(Slightly off topic: In my (short) experience with OTK, I stumbled upon scenarios where the automatic object initialization seems to not work: on an OTK exception and stackunwinding, Creo (the OTK DLL) crashed when there was an uninitialized OTK object in scope. No crash with previous initialization - unsure if my fault.)