Re: Is their any way to Run creo C++ ToolKit plugi...

VG_9645254 · ‎Sep 30, 2020

Hey, I am developing a C++ Toolkit plugin, but I don`t not want to load creotk.dat manually in config.pro or even in Aux Applications. Is their any way to alternative method to do that.

msteffke · ‎Sep 30, 2020

There are 5 registry file directories as known will be searched by Creo Parametric automatically when startup:

A. C:\ProgramData\PTC\Creo4\Plugins\<any sub folder>\
B. Working Directory
C. <Creo Parametric installation folder>\Common Files\<machine type>\text\<language>\
D. <Creo Parametric installation folder>\Common Files\text\
E. <Creo Parametric installation folder>\Common Files\text\<language>\

The searching order is: A->B->C->D->E, and Creo Paretric will stop searching if protk.dat / creotk.dat is found in B,C,D or E

e.g. if protk.dat exist in A,B,C,D,E separately, protk.dat in A will be loaded first then protk.dat in B, then Creo Parametric stop searching

remy · ‎Jun 20, 2022

For reference: https://www.ptc.com/en/support/article/cs320935

remy · ‎Oct 05, 2020

To address properly your request, there is a need to clarify why you need to run an application witout creotk.dat.

What is the purpose of opting for a different route than the official one?

FV · ‎Oct 07, 2020

@remy wrote:

To address properly your request, there is a need to clarify why you need to run an application witout creotk.dat.

What is the purpose of opting for a different route than the official one?

my guess the purpose of opting for a different route is that the official route with the exception of option B in Mark's answer requires executing installation scripts with elevated permissions and in case B,C,D,E there is quite high probability that creotk.dat would be misconfigured in case of multiple applications from multiple vendors.

A. C:\ProgramData\PTC\Creo4\Plugins\<any sub folder>\

for the custom app installation script this is environment variable LOCALAPPDATA evaluated in 'All Users' content as such ${LOCALAPPDATA}\PTC...

this folder is usually is read-only for non-privileged user and would require an assistance from IT to install a registry file there...
B. Working Directory (STARTUP directory)

for the installation script this is unknown entity. Either script needs to prompt an end user for the directory location - thus no silent install. Alternatively script could search computer mounted drives for clues - this is not good either.

if there was an existing creotk.dat file in than a special care needs to be taken to append the relevant entries instead of overriding the existing one...

C. <Creo Parametric installation folder>\Common Files\<machine type>\text\<language>\
D. <Creo Parametric installation folder>\Common Files\text\
E. <Creo Parametric installation folder>\Common Files\text\<language>\

all of those locations most likely will require elevated privileges to either write new file there or alter the existing one.

because only one creotk.dat from those locations is read in - this becomes a recipe for disaster when multiple vendors are trying to place their registry data there.

all of those location would force installation script to answer the question - which existing creotk.dat file to alter...

all of those locations would need an installation script to access HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PTC... computer registry setting in order to figure out <Creo installation folder>. This also most likely would require elevated permissions.

not to mention when new maintenance release would be installed the migration of creotk.dat file has to happen and quite often it would not happen without sysadmin intervention - not good either...

msteffke · ‎Oct 07, 2020

And looking at the original question, you don't have to load creotk.dat at all. Fact is you can load any named.dat file from any location. In the config.pro, you can set PROTKDAT FILELOCATION\NAME.DAT. (Im using Creo3, the Protkdat config.pro setting could be called creotkdat in newer versions).

Anyway the entry in Creo 3 looks like:

PROTKDAT J:\MYTOOLKITSTUFF\MYTK.DAT

remy · ‎Oct 08, 2020

All your objections are founded and fair.

Except maybe the part where you think that a start script cannot be set its starting directory. and the fact that the creotk.dat necessarily has to be appended.

I fail to understand exactly your positioning: you are a developer, can you explain why it is such a challenge to get admin rights?

When our customer deploy or migrate their application they work in collaboration with IT and our historic OEMs like 3D connexion have not raised the annoyance that you seem to complain. So unless you use the official route or unless you shed more information on your expectations and your constraints, then we'll poke around blindly.
good luck with that.

FV · ‎Oct 08, 2020

@remy wrote:

All your objections are founded and fair.

Except maybe the part where you think that a start script cannot be set its starting directory. and the fact that the creotk.dat necessarily has to be appended.

I fail to understand exactly your positioning: you are a developer, can you explain why it is such a challenge to get admin rights?

When our customer deploy or migrate their application they work in collaboration with IT and our historic OEMs like 3D connexion have not raised the annoyance that you seem to complain. So unless you use the official route or unless you shed more information on your expectations and your constraints, then we'll poke around blindly.
good luck with that.

Hello all,

Regarding startup directory - from an application developer standpoint, when one would like to install a registry file there. ( 'install' means to make a new when nothing there or to alter an existing one with relevant application entries) The main question to be answered is where the startup directory is on a customer's computer.

One way to acquire it is to prompt the end-user during installation process or to provide installation switch to supply startup directory value for the silent install. In case the app developer would like to be nice person and make a the installation process easier for the end user than the app developer has somehow to figure where this startup directory is. The one thing which is known, the startup directory must have 'drive-letter' so it must be on one of the mapped drives but those are a 'dynamic' thing the drive may or may not be mapped during the installation process. What I'm trying to convey is the process is not pretty...

Regarding appending data to protk.dat or creotk.dat - if a user has protk.dat already which starts some other applications and an installation of the new application would have overridden the existing one and a user would start a creo session and the first thing this user would see that the old apps were gone I'm sure that the new app would get a really unpleasant reputation...

Regarding admin rights. There is nothing wrong with that. Here is an edge use case: to provide a preproduction version or 'trail' version of an app - involving IT department in this process may not be the fastest route to get a feedback from the intended users...

Regarding deployment - since Creo 1 or Creo 2, I don't remember exactly when, with 'c:\ProgramData\PTC\...' (option A) the life of sysadmin got unquestionably better. In the old days either a space ball would stop working when some other app was installed or vice versa... The annoyance was loud and clear sometime around 2010 give or take a year or two during multiple pro/toolkit tech committee sessions.

HIH.

FV · ‎Oct 05, 2020

maybe a call to ProToolkitDllLoad().

remy · ‎Oct 08, 2020

When you read the documentation, it tells that this function calls another application.
This still requires that the calling application be started with a creotk.dat file.

FV · ‎Oct 08, 2020

reading the documentation...

Pro/Toolkit or OTK asynchronous application does not need a registry file to start.
Web/Link application does not need a registry file to start.
J-Link asynchronous application does not need a registry file to start.
J-Link attached to Pro/Program does not need a registry file to start.

Pro/Toolkit, OTK, Web/Link, OTK-Java (J-link) user guides, all of them have 'Task Based Application Libraries' chapter.

start an async app, make it call pfcSession.BaseSession.LoadProToolkitDll(...) or ProToolkitDllLoad(...), exit async app.

remy · ‎Oct 08, 2020

Thank you for your clarification. Your reply finally makes sense now if VG needs to use an asynchronous application.

VG_9645254 initially referred to a "plugin" hence implying a synchronous application.

FV · ‎Oct 08, 2020

the application is 'plugin' and it is synchronous

the 'loader-application' is asynchronous and has one task which is to call ProToolkitDllLoad().

something like this:

async:

//bar.c
int main(argv, argc)
{
char dll_path = "foo.dll";
ProName app_name = L"Foo";
ProError  err = ProEngineerConnect(...);
if( PRO_TK_NO_ERROR == err){
   ProToolkitDllLoad(app_name, dll_path, ...);
}
return 0;
}

sync plugin ( foo app):

//foo.c
extern "C" int user_initialize(...)
{
//the actual app
}

if pro/e is up and running, and user starts 'bar.exe' from a shell the 'foo' app should be initialized in pro/e session.

some logic should be applied while attempting to connect to the intended pro/e session if multiple are running and so on...

Is their any way to Run creo C++ ToolKit plugin without loading creotk.dat

Is their any way to Run creo C++ ToolKit plugin without loading creotk.dat