License needed to run my Pro/Toolkit add-ins

I received a comment on an older post of mine HOWTO: Example Pro/Toolkit Application using Visual Studio 2005 from Hans who mentioned that he was unable to run my Pro/Toolkit add-in that was attached with that post. (For convenience the following is the same attachment)



The specific error he received was:

The Pro/TOOLKIT application "ProE_Proj" was not unlocked before distribution to your site.
Please contact the provider of "ProE_Proj" for assistance.

This error is the result of a lack of a Pro/Toolkit license on the PC on which you are deploying my add-in.

Reason for Error
I intended this blog for developers of Pro/Toolkit, SolidWorks and other CAD API applications. So the assumption I make is the availability of the required developer license on the PC where these applications are to be developed. The Visual Studio project and source code that I post are not intended for deployment on end-user PC. I do not pay for a Pro/Engineer or Pro/Toolkit license myself. So do not have the rights to distribute the binary executable code (either DLL or EXE). In order to use my add-ins on an end-user PC you will need to have a Pro/Toolkit or SolidWorks license, as applicable.

Solution
 To deploy a Pro/Toolkit add-in (e.g. to deploy my ProE_Proj on a PC without Pro/Toolkit license) follow these steps:

• From a development workstation which has Pro/Toolkit license execute the following command:

C:\Program Files\proeWildfire 3.0\i486_nt\obj\protk_unlock.exe 'one or more pro/toolkit dll or exe names '

• Once unlocked you can deploy the add-in to end-user PC without them needing Pro/Toolkit license on their PC. To learn how to write installers to deploy your add-in, refer to my last post Pro/Toolkit Add-in registration.

Still problems?
If you are still having problems with development or deployment of the Pro/Toolkit add-in, then post a comment and I will respond with a solution if I have one.

Pro/Toolkit Add-in registration

In one of my previous posts HOWTO: Example Pro/Toolkit Application using Visual Studio 2005 I described how to create protk.dat files necessary to enable Pro/Engineer to discover your Pro/Toolkit add-ins. In that post the protk.dat file was placed in the same path as your executable. This simplified your development and debugging process.

But once you are done with all development and want to package your add-in for delivery to the customer you can leave the protk.dat in the same location as your add-in unless you plan to put your executable in the Pro/Engineer directory - which is the worst thing you can do.

So where should you put your protk.dat file? Well the tkuse.pdf (found under C:\Program Files\proeWildfire 3.0\protoolkit) gives the following advice to Pro/Toolkit developers.

Pro/ENGINEER searches for the registry file as follows:

• In the absolute path specified in the “PROTKDAT”, “PRODEVDAT”, and “TOOLKIT_REGISTRY_FILE” statements in the Pro/ENGINEER configuration file.
• For the files named protk.dat or prodev.dat in the following locations:

1. Current directory
2. < Pro/ENGINEER >/< MACHINE >text
3. < Pro/ENGINEER >/text

In the preceeding locations, the variables are as follows:

• < Pro/ENGINEER >—The Pro/ENGINEER loadpoint (not the Pro/TOOLKIT loadpoint).
• < MACHINE >—The machine-specific subdirectory (such as sgi_elf2 or i486_nt).

If more than one registry file having the same filename exists in this search path, Pro/ENGINEER stops searching after finding the first instance of the file and starts all the Pro/TOOLKIT applications specified in it. If more than one registry file having different filenames exist in this search path, Pro/ENGINEER stops searching after finding one instance of each of them and starts all the Pro/TOOLKIT applications specified in them.
Note:

• Option 1 is normally used during development, because the Pro/TOOLKIT application is seen only if you start Pro/ENGINEER from the specific directory that contains the registry file.
• Option 3 is recommended when making an end-user installation, because it makes sure that the registry file is found no matter what directory is used to start Pro/ENGINEER.

So according to PTC we should put our protk.dat files in the < Pro/ENGINEER >\text folder which is typically C:\Program Files\proeWildfire 3.0\text.

Be careful
Do not overwrite the protk.dat file in the < Pro/Engineer >\text folder as other add-ins may have appended their protk.dat registry file into that file. Append your protk.dat to the protk.dat file in the < Pro/ENGINEER >/text folder. Also when uninstalling take care to not delete the protk.dat files, as that would disable other add-ins. Simply delete the lines in that protk.dat file that you wrote during installation of your add-in. NOTE: Do not just make a copy of the protk.dat in< Pro/ENGINEER >\text folder to a temporary location during installation and then replace it when uninstalling your application. This will disable Pro/Toolkit applications installed after your own.

So what should be done and How to do this?
To summarize we need to achieve the following to register and deregister the Pro/Toolkit addin with Pro/Engineer upon installation and uninstallation respectively:

1. On install append the add-ins registration information to the protk.dat file in < Pro/ENGINEER >\text
2. On uninstall delete the lines of text we appended to the protk.dat file in < Pro/ENGINEER >\text

I personally use the NSIS scriptable install to create Pro/Toolkit applications. NSIS is an open source system to create Windows installers. If you use NSIS then the following tips should help you to address the above requirements.

• INSTALLATION:
• Create a section, named something like "AppendProTKDAT".
• Call FileOpen in "append" mode
• Call FileSeek with "offset" at "0" with "END" mode - This is very important, since FileOpen always positions the file's cursor at the beginning of the file. We want to append our protk.dat registry lines to the end of the file - So basically call after FileOpen
  FileSeek $0 0 END
  
• Call FileWrite repeatedly to write the various lines
          FileWriteByte ${FilePathName} "13"
          FileWriteByte ${FilePathName} "10"
          ; Carriage Return / Line Feed
          FileWriteByte ${FilePathName} "13"
          FileWriteByte ${FilePathName} "10"
          FileWrite ${FilePathName} "NAME             ${name_of_prod}"
  
• Call FileClose
• UNINSTALL
• To delete the lines of text we appended to the protk.dat file call RemoveAfterLine as specified in the following NSIS Function (note: this is a user contributed Function).
• So in my case I called it as follows (the $\r$\n is for "new line"):
  Push "NAME             ${PRODUCT_NAME}$\r$\n" ;(here ${PRODUCT_NAME} is something I have defined at the beginning of the script to be the name of my product, as written to the protk.dat)
  Push "END$\r$\n"
  Call un.RemoveAfterLine
  

A Few Gotchas
While creating the installer with NSIS I ran into a weird problem. During install/uninstall with the NSIS-created installer, the protk.dat file would get appended to properly but for some reason the permissions on the file would change from "readable by Users" to "readable by Administrator only". Since I could not find a fix or a mention for this on NSIS' website I fixed it as follows:

• On Windows XP (and possibly other Windows OS too) call "CACLS.EXE" as follows during install and uninstall -
  ExecWait '"$SYSDIR\cmd.exe" /C echo Y|$SYSDIR\cacls.exe "${PROTKDAT_INSTALL_DIR}" /G everyone:R administrators:f' $0
• The "echo" part is required since CACLS.EXE requires user input at the command prompt for a "Y" or an "N". So with the "echo" we are simply replicating that behavior.
  

Comments?
I am not attaching the source code directly, as I have not found a generic way to present my NSIS code without making it very application specific. If the sample stuff I have posted above is not enough, leave a comment for me and I will post whatever you need after stripping application-specific strings and code.