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.