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.

Pro/Toolkit, SolidWorks API Development Tools (C++ Episode)

Continuing the topic I started discussing in my last post with Visual C++ and Pro/Toolkit development tools.

Remember you can use TortoiseSVN with any file type (does better with text, since merging is possible with text files), so I don't mention it separately here.

Visual C++
Logging Tools:
Pantheios
Logging in Visual C++ is unfortunately not the easiest tool to find. There are many that pop up e.g. Log4Cpp, Log4Cplus, log4cxx etc. but I was not able to build any of these successfully. So I finally turned to Pantheios and found it as easy to use as NLog though the configuration is quite different and is not done through configuration files like NLog. You have to build the Pantheios libraries yourself, so don't forget to refer to the Pantheios Library Selector Tool to make sure you use the right libraries with your code.

Now keep in mind that Pantheios describes itself as a logging API rather than a logging tool meaning it does not have the choice of targets that NLog provides (of course there is no NLog for pure C++, only in mixed managed/native mode). So Pantheios allows you to write to files on your hard disk and thats it. For more target choices you need to add one of the previously mentioned logging tools (viz. log4cpp, log4cplus or log4cxx) into the mix. But I have found no need to do so. I use the stock back and front ends that come with Pantheios and write my log messages to a file on the hard disk.

Pantheios uses a BSD-style license.

Testing Tools
CppUnit
CppUnit is probably the most well known unit testing frameworks available for C++. CppUnit is licensed under the GPL. I have found it easy to setup and use even though you need a few macro statements to write even an empty unit test. For a thorough review of the unit tests available I refer you to a post by Noel Llopis posted a few years ago (2004) but still very relevant. After reading Noel's post I stuck with CppUnit as it offers most C++-like experience which most developers programming Pro/Toolkit are comfortable with, though I would love to have some time to study Boost.Test since I love the Boost libraries.

CeeFIT
I mentioned FIT with my last post and CeeFIT is the C++ implementation of FIT. The following is just an excerpt from my previous post and is just as relevant in this section:

FIT stands for "Framework for Integrated Test" and enables developers to place the input data in HTML tables so that it is easy to read (both by Human users and software) and outputs the resulting data back in that same HTML table (with a different file name if you prefer) with colored markup so that it is easy to tell which test passed and which did not. FIT is described as a collaboration tool and I have successfully used it as such, by using those HTML files to contain complete descriptions of functionality of the application being developed and to show current status of development. Make sure you download the right version of the FIT libraries as it comes in various flavors e.g. Java, C++, .NET etc.

I am unaware of other integrated test tools that are as simple to use as FIT and are Open Source or at the very least free to download and use for personal applications. If you know of any please let me know.

Database
SQLite
I mentioned SQLite also in my last post as an excellent, completely free and easy to use database engine. To use SQLite with C++ you need to use a wrapper and many are listed at SQLite's wrapper page. I have personally used CppSQLite hosted on CodeProject and found it really easy to work with.

NOTE on Using CppUnit and CeeFIT with Pro/Toolkit applications
Keep in mind that using CppUnit with Pro/Toolkit applications would require you to run Pro/Engineer in batch mode, which I would definitely advise against as that would slow down your build process and does not quite fit in the realm of unit tests. So you are better off writing functional or integrated tests for your Pro/Toolkit applications.

To write integrated tests for your Pro/Toolkit application using CeeFIT remain tuned in to my blog. I am working on a workspace that will let you do just that and will post the code if and when I am successful.

Comments or suggestions?

Pro/Toolkit, SolidWorks API Development Tools (C# Episode)

I follow CAD related blogs often and happened to come by the following interesting post at http://ExtensibleCAD.com. As someone who develops SolidWorks API-based (and Pro/Toolkit) applications I thought I could post a similar list of tools that I use in my applications but have the advantage of being Open Source so that they are available to all with little restriction and that too on Microsoft Windows.

I develop with both Visual C# and Visual C++ and break down the tools based on the language and the CAD system they can be used with. If you develop for SolidWorks then you can use either Visual C# or Visual C++ (although SolidWorks is pushing C# more than C++). On the other hand with Pro/Toolkit you are somewhat stuck with C++.

Visual C#
Logging Tools:
NLog
Every good programmer needs a good logging tool. I suggest using NLog. This has to be the simplest logging tool ever. I tried to use log4net by Apache but to be honest it has a learning curve that I did not have time for. The best part of NLog is that by simply modifying a configuration file, you can turn off logging completely without a single change to your source code. (I am sure log4net also allows this or something equally simple). NLog is distributed under the BSD license. If for some reason you don't like NLog or log4net then there are others you can take a stab at.

Testing Tools:
NUnit
Who in this day and age writes code without at least a unit test framework that runs as part of your build process? (not me). Well fortunately NUnit is really easy to use and has a license based on zlib which allows commercial use.

There are other unit test frameworks if you are unsatisfied with NUnit (some people are) e.g. xUnit.net, MbUnit etc. I have heard great things about MbUnit especially how extensible it is but personally NUnit does the job for me so have not let my eye wander.

FIT
FIT stands for "Framework for Integrated Test" and enables developers to place the input data in HTML tables so that it is easy to read (both by Human users and software) and outputs the resulting data back in that same HTML table (with a different file name if you prefer) with colored markup so that it is easy to tell which test passed and which did not. FIT is described as a collaboration tool and I have successfully used it as such, by using those HTML files to contain complete descriptions of functionality of the application being developed and to show current status of development. Make sure you download the right version of the FIT libraries as it comes in various flavors e.g. Java, C++, .NET etc.

I am unaware of other integrated test tools that are as simple to use as FIT and are Open Source or at the very least free to download and use for personal applications. If you know of any please let me know.

Database
SQLite for .NET
Most developers have heard of SQLite, which is an excellent self-contained database engine. The SQLite code has been dedicated to public domain, so it is free for all uses and does not come in multiple flavors like SQL Server Express. Everything SQLite has to offer you get free and no installation is needed. To use SQLite with .NET I suggest using System.Data.SQLite which has a .NET provider to manipulate SQLite databases. System.Data.SQLite too sits in public domain.

Language Independent
TortoiseSVN
This is a must have tool for all developers at least for those who use Microsoft Windows and don't already use some other version control system.

NOTE on Unit Testing and CAD API
Keep in mind that if you want to test functions that call SolidWorks API then you need to run SolidWorks in batch mode if you want it to work. I personally do not suggest unit testing functions that call SolidWorks API as it would slow down the build (referring to local build on developers' machine and not build server) process and in my opinion is not what unit testing is intended to be. Additionally the unit tests would not know how to handle calls to SolidWorks API (if SolidWorks is not running and/or you are not connected to a SolidWorks instance). The idea of mock objects may work but that is beyond the scope of this post and may require the CAD-API developer to get quite involved.

Instead I would suggest using a functional test framework or even integrated test framework for testing functions that call SolidWorks API. Since most of the time the function or integrated test frameworks do not run as part of the local build (perhaps as part of build server), you could run such tests on functions or your system even if they call SolidWorks API.

Comments?
Development Tools that I use with Visual C++ and Pro/Toolkit is coming with my next post. Do leave me a comment if you have a tool that you prefer.