Monday, September 08, 2008

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.

  • 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.
      • 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
      • 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.
    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.

    No comments:

    Post a Comment