Pro/Toolkit: Simplifying Your protk.dat File with Environment Variables

If you find yourself editing your protk.dat files because you are changing the location of the application or you are using multiple hardware architectures (i.e. Unix and Windows, Win32 and Win64, etc), STOP! Put down the mouse, and slowly step away from the keyboard.

If you use environment variable creatively, you will need one protk.dat file for all of your installations. That's it, just one. Unix and Windows you ask? YES! 32 bit and 64 bit Windows? YES!

The first thing you need to do is to setup an environment variable for the install folder of your application. Call it what you want, but be consistent. I am going to give examples here about the open source Pro/ENGINEER to BRL CAD converter. I'll use the environment variable PROE2BRL_INSTALL for the install folder.

The resulting protk.dat file looks like this:

name PROE2BRL
startup dll
exec_file $PROE2BRL_INSTALL/proe2brl.dll
text_dir $PROE2BRL_INSTALL/text
allow_stop TRUE
end

 
I know what you're thinking, you think you'll have to change those paths for Windows machines. WRONG! It's a little known secret that Pro/ENGINEER on Windows can handle unix style pathing and environment variable syntax, and not just in protk.dat files. This includes the config.pro file. It may seem strange to those die-hard Windows guys, but it works.

Now the 64 bit Windows guy in the audience (I'll call him Dustin), shouts out "What if we have 32 bit and 64 bit DLL's?!" Well Dustin, no problem there either because Pro/ENGINEER sets some platform specific environment variables that we can use.

We can separate the 32 bit and 64 bit DLL's into two folders. For Windows, this would be "i486_nt" for 32 bit DLL's and "x86e_win64" for 64 bit DLL's. If we plug in the MC environment variable, Pro/ENGINEER uses the correct DLL based on the current architecture.

The resulting protk.dat file looks like this:

name PROE2BRL
startup dll
exec_file $PROE2BRL_INSTALL/$mc/proe2brl.dll
text_dir $PROE2BRL_INSTALL/text
allow_stop TRUE
end

 
Now the Unix guys, bored with talk of mere a 32 bit application, rant "On Unix, our DLL's are called shared objects and have a .so extension and ... blah blah blah ...". Again, not a problem. If that's a concern, setup another environment variable, let's call it PROE2BRL_EXEC. On Unix this can be set to "proe2brl.so" and on Windows "proe2brl.dll". (Or, just call it "proe2brl.dll" and skip this step)

The resulting protk.dat file looks like this:

name PROE2BRL
startup dll
exec_file $PROE2BRL_INSTALL/$mc/$PROE2BRL_EXEC
text_dir $PROE2BRL_INSTALL/text
allow_stop TRUE
end

 

In the config.pro, we can use this:

protkdat $PROE2BRL_INSTALL/protk.dat

 

These techniques get us much closer to the mythical "one install" for all platforms. Also be sure to check out my previous article on how to conditionally load your Pro/Toollkit applications.


Questions and comments are always welcome, either here on my blog or at MarcMettes@InversionConsulting.com.

Conditional Loading of Pro/Toolkit Applications

Pro/Toolkit applications often provide great value. However, not every user needs to be running all applications all of the time. Pro/Toolkit provides a few options for the startup of applications, but these options apply to all users. There aren't any options there to give you direct control on a per user basis. This can be accomplished, however, just in a different way, via the config.pro file.

The trick is to use an environment variable for the value of the PROTKDAT option. The syntax (for both unix and windows) would look like this:

PROTKDAT $SOME_TK_APP

For users that need the application, set the environment variable before Pro/Engineer starts to contain the path and file name of the Pro/Toolkit application registry file.

Here are some examples:

Unix C Shell:
setenv SOME_TK_APP /opt/myprogram/protk.dat

Unix Bourne/Bash Shell:
SOME_TK_APP=/opt/myprogram/protk.dat
export SOME_TK_APP

Windows Batch File:
set SOME_TK_APP=N:\apps\myprogram\protk.dat

In WF3 and earlier, when Pro/Engineer reads the config.pro, it will check the value of the environment variable. If the environment variable is not defined, or doesn't contain the path to a Pro/Toolkit registry file, the config.pro option is silently ignored. Otherwise, it reads in the registry file data and starts the application as instructed.

In WF4, things get a little different. If your environment variable is empty or points to a non-existent file, a dialog box will appear that mentions this "problem". Since the only option in the dialog box is an OK button, the dialog box seems rather pointless and and makes for an annoying user experience.

Anyway, to workaround this "bug", simply have the environment variable point to an empty file when the application is not needed. As a result of this, in my Pro/Toolkit app installs, I typically have two Pro/Toolkit registry files. One respresents the "on" state, while the other (the empty file) respresents the "off" state.

As an alternative to an empty file, the "off" state registry file could have the DELAY_START option set to TRUE. This would still allow for the program to be used, but would not start it up when Pro/Engineer starts. This is a little more flexible because otherwise the application is completely unavailable to the user.


Be sure to read my followup article, Pro/Toolkit: Simplifying Your protk.dat File with Environment Variables.