Open Source, Computer-Aided Design, Pro/Toolkit, SolidWorks API

Lesson 2: IntegratedTests, IntegratedTests and more IntegratedTests

2012-03-12T17:00:00.000-05:00

Why Integrated Tests?
One of the biggest goals I had in the development of the latest version of FlexiDesign was to ramp up the number of automated tests that run as part of our build system. And I am talking about Integrated Tests not unit or functional (those are important too, of course). I far prefer Integrated Tests primarily because it checks the full product from beginning to end.

Integrated Tests of a CAD add-in? Really?
But how do you test a product that is an add-in to a CAD system? The CAD system controls when the add-in product is loaded and when it is available to the end-user to interact with through a UI. It is not an easy task to simulate all these actions in an automated test (something that runs with no developer/user interaction whatsoever).

But there is a way.

So what is the solution?
If you have read my previous blog posts, then you may have found one of my downloads SWXBATCH_CEEFIT which couples the open source Integrated Test Framework (CEEFIT) with a simple wrapper to start SWX, call some SWX API, verify the output using CEEFIT, and then stop SWX. If you are interested, then read that article or even email me at ganeshram iyer [at] gmail dot com.

You can download the framework here:

http://ossandcad.googlecode.com/files/swxbatch_ceefit_6_16_2009.zip

Or you can browse the source code here:

https://ossandcad.googlecode.com/svn/trunk/swxbatch_ceefit

Extending SWXBATCH_CEEFIT
The download assumes that you have SolidWorks already installed at a specific path (I think it is C:\Program Files\SolidWorks). This is important, because SolidWorks registers its API in the Windows Registry and SWXBATCH_CEEFIT relies on that registration to call the SWX API over COM.

By default SWXBATCH_CEEFIT calls SolidWorks 2009, but making it call other versions of SolidWorks is pretty easy too:

Simply change the headers that you #include in SWX.cpp
If you want to build against multiple SWX versions, then create a new configuration in the project, add a preprocessor definition and use that to #ifdef which SWX headers to #include. e.g.:

#ifdef SWX2011
#include "swx2011\amapp.h"
#include "swx2011\swpublished_i.h"
#include "swx2011\swconst.h"
#else
// Solidworks includes for e.g. 2009
#include "amapp.h"
#include "swpublished_i.h"
#include "swconst.h"
#endif

Of course you need to have the specific version of SWX installed too :)

SWXBATCH_CEEFIT also needs a valid SWX License to run, since it actually starts SWX to "do its business".

Summary

SWXBATCH_CEEFIT runs on 32-bit, 64-bit, Windows XP, Vista, and 7, SolidWorks 2009, 2010, 2011, 2012. So the coverage of test platforms and OS is pretty comprehensive, though the limitation is that the specific SWX version itself needs to run on the OS - you may have to check with SWX support to determine those details. You may have to add some configurations yourself though (or email me and I can send you the latest version I have that has all the required settings).

We use this to test the ins and outs of FlexiDesign and it dramatically helps improve the stability of the product. We run Integrated Tests on FlexiDesign every night - it takes a few hours to run the entire thing due to all the combinations tested - and we only need to edit/add the tests when we have a design change that changes the behavior of the product - which is primarily on major functionality change or major feature addition or major bug change (read: not often).

In short, if you develop CAD Addins (viz. SolidWorks), try out SWXBATCH_CEEFIT and let me know if you find it useful. We certainly do.

Solution for "Windows Scripting Host: Can't find a script engine 'javascript'"

2012-03-11T17:24:00.000-05:00

Problem
Using TortoiseSVN's 'Edit Conflicts' on conflicts in DOCX files, used to throw up a message box with a text similar to:

Windows Script Host: Can't find a script engine "javascript" for C:\Program Files\TortoiseSVN\Diff-Scripts\merge-docx.js

Solution
To solve this problem, I initially thought the problem was with TortoiseSVN. Was I barking up the wrong tree!

Turns out that the problem is related to Windows Script Host and the solution is much simpler:

Open a Command Prompt with Administrative privileges (cmd)
Simply enter

regsvr32 jscript.dll
There isn't a 3rd step :-)

Blogging my solution as I didn't find a straight forward answer to my problem. Hope you find it useful.

Lesson 1: Licensing is part of Software Engineering

2011-11-18T17:00:00.000-06:00

For the better part of this year, 2011, I was involved in the commercial release of a novel 2D to 3D conversion software, FlexiDesign. During the development, test and release to manufacturing (RTM) of FlexiDesign I picked up a few nuggets of knowledge and experience that I don't hear being discussed often, especially in this cloud-centric world. Perhaps it was discussed fervently a decade or two ago when desktop technologies were cool, but still relevant today since not all technologies are ready for the cloud (just yet).

One of the lessons I learned during the final development sprint was how important it is to incorporate the requirements of a License Manager early in the development cycle.

Briefly (for the impatient):

The License Manager requirements should be considered as part of the rest of your Software Engineering tasks
The License Manager should support Network Licenses
The License Manager must be customizable (preferably through API)
The License Manager should support DLLs in addition to EXEs
The License Manager should preferably be the same as the host CAD system

In Detail (for those of you who are still reading):

The License Manager is part of Software Engineering
While most desktop applications can incorporate an off-the-shelf License Manager, the requirement has to be dealt with more carefully when you are developing CAD Add-Ins. While you can simply bolt on many License Managers on to a regular non-add-in product, it may not be possible to do so with CAD add-in products, since the CAD system may need to talk some parts of your product without any limitations and you want to protect/lock other parts of you product. For example to register an add-in with SolidWorks, you need to make sure that the ConnectToSW(), DisconnectFromSW(), RegisterFunction() and UnregisterFunction() are not locked away by your License Manager. Else your add-in may not load at all.
The License Manager should support Network Licenses
Another requirement that has high priority is the availability of Network Licenses. CAD Administrators don't want to maintain separate licenses per PC, since that is very inefficient and time consuming. So the License Manager you select must be available over the network for your add-in to connect to validate the license. This also limits the potential candidates of License Managers leaving you with even fewer choices.
Customizable License Manager (preferably through API) AND
License Manager should support DLLs
With FlexiDesign, we realized that the default behavior of most License Managers is to prevent the licensed software from running. With CAD systems, add-ins are loaded on startup and preventing the DLL from loading (e.g. if the license for your product has expired) might prevent the CAD system from starting up - which most people may agree is not a good thing.
Same License Manager as the host CAD
If at all possible, your License Manager should be the same as the the one your CAD system uses. This is not normally possible, but if you build for Pro/Engineer then I believe they use FlexLM License Manager (http://www.flexerasoftware.com/products/software-licensing.htm). SolidWorks seems to use an in-house build License Manager - SolidNetWork License Administrator (if I got the name right).

So after all those details, the License Manager we selected for FlexiDesign is ........ for me to know and you to find out. Sorry. Can't reveal company information.

If you are interested in cracking software licenses, then I found a nice starter article at http://www.zabkat.com/blog/30Jul11-dummy-software-cracks.htm, though I don't personally recommend such possibly illegal activities.

Back after a long break

2011-09-05T14:18:00.001-05:00

If you have been following my blog I apologize for not posting for so long. My last post was in Nov 2010. If you were wondering where I disappeared to, rest assured I have a valid reason.

I have never spoken about my day job and I finally am able to. I work for Imagecom Inc. a company in Arlington TX that has spent the last few years developing an absolutely unique, radical CAD solution. While the product (which I will talk of soon, hold on to your hats), is not a new idea, the solution that we have come up with is one that is not available anywhere else.

The product is called FlexiDesign. It is a semi-automated 2D drawing to 3D model conversion tool that fits in the CAD system of your choice. The resulting 3D model is fully parametric and feature-based.

If you have worked in the CAD domain, either modeling or developing CAD apps or add-ins, you have definitely heard of automated, semi-automated or manual 2D to 3D conversion tools. Some are:

2D to 3D Tool for Autodesk Inventor
SolidWorks 2D to 3D - The 2nd video titled "Leveraging existing 2D Design Data" shows how SolidWork's 2D to 3D works
PTC Autobuildz - A bit dated, too, but should show how Autobuildz works.

There may be others, but these are the more well known ones and are from the big boys, each part of the oligopoly that is the CAD industry.

In the next few posts I will be talking about some of my experiences developing a CAD Add-in product/solution. While my plans are not finalized, I hope to discuss topics like licensing, CAD API (the good and the bad), development practices, and my favorite topic - testing. A lot of the tools that I have uploaded as part of this blog were instrumental in developing and deploying FlexiDesign.

So keep an eye on this blog and I will keep it updated as often as possible.

New license for my SWXBATCH_CEEFIT project

2010-11-04T19:00:00.020-05:00

Have you heard that the CeeFIT website is back up and running? Well it came back up a few months ago. Thank Heavens.

But the author kindly pointed out to me that I was not complying with the original license of the CeeFIT website, i.e. the "GNU GENERAL PUBLIC LICENSE Version 2" as mentioned here. So to comply I had to change the license of one my projects, specifically the SWXBATCH_CEEFIT. Unfortunately Google Code (where I host the source code of my projects) doesn't allow me to specify different licenses for individual projects. So I had to change the license associated with all my projects to the GPL v2, though this only really affects the SWXBATCH_CEEFIT project. I have added a note on the home page to inform of the changes, but am hoping repeating this information on my blog will help clarify the issue.

As for my other projects, you are free to do what you want with it since I have not attached any license to the projects themselves.

SO DOES THIS AFFECT YOU?

The SWXBATCH_CEEFIT is primarily intended as a test framework. If you use it as intended and don't distribute your test framework to your clients (i.e. you only use the test framework in house) then the license change from 'New BSD' to 'GPL' doesn't affect you. If you are unable to comply with this requirement, I am afraid I can't help, since the GPL is viral in that way.

My Continuous Integration Build is too fast

2010-10-08T17:30:00.015-05:00

We all know of Continuous Integration and the importance of having really fast builds, especially on a central build server. If not read up on http://martinfowler.com/articles/continuousIntegration.html. You may have also heard that a good build time to shoot for is ~10-15 minutes for each regular build (not accounting for nightly builds) at least for small-medium sized projects. If you are interested there are numerous discussions and posts on this. So like any good build engineer striving for efficiency and speed I attempted to reduce build times for the project I work on, at least till now.

Some details on the project build:

Our projects are currently in Visual Studio 2005 (we are in the process of upgrading to 2010 but that is another story).
Almost all our projects are native C++ (i.e. Unmanaged code) with a sprinkling of C# (i.e. Managed code)
We use CruiseControl.NET but use the Visual Studio Task (which internally executes devenv.com to rebuild the Visual Studio 2005 projects).
Monitor every minute for a developer's commit to the repository
Run Unit tests
Run Functional tests
Run Integrated tests (nightly builds only)
Notify developers of build status
Licensing and Unlocking
Package (ZIP, installer)
Deploy (for download by our modelers/testers)

This entire process takes about 12-15 minutes on our build server which is not the newest piece of hardware (in fact was purchased somewhere around 2001/2002). The nightly builds could take more than an hour since we run Integrated tests too, on the same build server. Not too shabby but we could definitely do better.

The simplest way to speed up the build would be to purchase a new build server and cannibalize the old one or simply re-purpose it.

Licensing and what now?

But here's the catch. In case you missed it, I highlighted "Licensing and Unlocking" in the steps above for that reason. What is that step you wonder? Well I work with Pro/Toolkit applications, the API for Pro/Engineer. If you want to deliver programs that use Pro/Tookit to your customers (who most likely will not have a license for Pro/Toolkit) then PTC provides a little executable called protk_unlock.exe that simply "unlocks" your Pro/Toolkit application to enable it to run on PC that don't have the license for Pro/Toolkit. If you were not aware of it, "unlocking" your Pro/Toolkit application will cause the PTC License Server to hold your Pro/Toolkit license for 15 minutes (yes, you read that right - FIFTEEN minutes). Of course all this is common knowledge.

'14' is the wrong answer

So what if my average build completes in less than 14 minutes? Well CruiseControl.NET uses a "update before you build" style to build your projects regularly. Which means that if two developers commit to the repository within a minute then there is a good chance that the two commits would be rolled into a single build (this is different from the process that some Continuous Integration tools use where a commit triggers a build - must be nice to own these nicer tools). But the worst case scenario is that "if for some reason the average build time is less than, say, 14 minutes AND the next build starts within the minute, THEN there is a good chance that the second build will not be able to 'unlock' its Pro/Toolkit application, since protk_unlock holds the license for 15 minutes and our build has finished in less than that time."

Now what?

So what is the solution to this problem? Well, if you have the money, you could always add a 2nd Pro/Toolkit license to that single build server, so that you always have one license available every 15 minutes.

Or you could do what I did - YOUR BUILD IS TOO FAST, SLOW IT DOWN.

Almost makes me want to cry. Oh well. What other idiocracies have you encountered in your build scenarios?

Note: I linked to a cached page from Google's server for the following link http://openmakesoftware.com/mavericks/2009/02/17/check-out-code-post-commit-not-pre-build/ since the original didn't show when I posted this article.

Will the real 'PHI' symbol please stand up?

2010-08-13T17:30:00.011-05:00

In my last post SolidWorks Hole Size and Extended ASCII codes I had mentioned that I needed to input the 'PHI' symbol when creating a Wizard Simple Hole in SolidWorks using the SolidWorks API for Visual C++.

Well it turns out that while my mind was in the right place, I probably should have taken that left turn at Albuquerque. So lets revisit that topic again. It seems that using Extended ASCII codes for this job was the wrong solution, though it did lead me to find out more about specifying symbols using Unicode, since I figured that I need to specify the PHI symbol using Unicode.

So now the questions are "what is the Unicode character for the PHI symbol?" and "how do we specify that character in C++"?

Lets answer the more difficult of the two questions first, which is what this post is all about.

What is the Unicode character the PHI symbol?
Well turns out that there are numerous ways to express the same symbol (at least they are the same in that they are all called PHI). Here are a few Unicode characters that MS Windows recognizes as PHI symbols:

U+0278 (http://www.fileformat.info/info/unicode/char/278/index.htm)
U+03D5 (http://www.fileformat.info/info/unicode/char/3d5/index.htm)
U+03A6 (http://www.fileformat.info/info/unicode/char/03a6/index.htm)
U+00D8 (http://www.fileformat.info/info/unicode/char/d8/index.htm)

So which one is the one we need? Well its the last one. Why? Because thats the only one that SolidWorks will accept and create a hole with and the only one that looks like the Mathematical symbol PHI (Ø - see note below). The rest may look like PHI but they are not the Real McCoy.

Now that we have the Unicode character to use, comes the easier question:

How do we specify Unicode characters in C++?
Surprisingly the answer is similar to specifying Extended ASCII codes. Instead of using a "\x" we simply use a "\u". Here is what it looks like:

CComBSTR size(L"\u00D80.15");

Breaking it down:

The "L" is to specify that this is Unicode.
The "\u" is to specify Unicode characters in literal strings
And as we saw as the answer to the first question, the "00D8" (thats ZeroZeroD8) is the PHI symbol
The trailing 0.15 is simply a size that SolidWorks Hole could have
BUT unlike Extended ASCII we can specify the non-Unicode portions of the string literal, using regular characters i.e. the "0.15" part.

I guess we learn something new everyday.

So do you use Unicode characters in your literal strings often? What method do you use to find the right code? Let me know.

NOTE:
IF YOU CAN'T SEE THE PHI SYMBOL ITSELF AT THE SPECIFIED LOCATION THEN YOUR BROWSER DOESN'T UNDERSTAND UNICODE CHARACTERS. TO FIX THIS PROBLEM GET A BETTER BROWSER.

SolidWorks Hole Size and Extended ASCII codes

2010-07-19T18:00:00.002-05:00

If you have tried to create a WizardHole of type "Simple Wizard Hole" using C++ API (not .NET but native C++) then you surely have run into this problem: "How to specify the size of the hole?"

SolidWorks needs the "PHI" symbol in Hole Size

SolidWorks' new FeatureManager::HoleWizard3 API fixes a problem we (colleagues of mine from the company I work for and I) have noticed in previous versions of the WizardHole API (ping me if you want details on that problem, but not relevant to this post, so am not providing details here). But the new API requires you to specify the size of the WizardHole in string literal format (or BSTR or CComBSTR). Typically this is not a problem but for the case of the "Simple Wizard Hole" SolidWorks expects the "diameter symol" to be input as part of the size if the "Standard" selected is "ANSI Metric".

Using Extended ASCII Table
So the API call looks something like this:

featmgr->HoleWizard3(eHoleType, eHoleStd, fastenerType, size, endCond, dRadius*2.0, dDepth, values[0], values[1], values[2], values[3], values[4], values[5], values[6], values[7], values[8], values[9], values[10], values[11], threadclass, FALSE, TRUE, TRUE, TRUE, TRUE, FALSE, &hole);

Ignore the other parameters for now and focus on the highlighted "size" parameter. To specify a size of "0.15mm" for "ANSI Metric" you would need to prepend the "phi" symbol to "0.15mm". How would you do this? Well you use extended ASCII codes, of course. Don't remember your extended ASCII codes? Well you could Google it, but this link (http://www.asciitable.com/) should suffice. The "size" string value should look something like this (for size 0.15):

CComBSTR size(L"\x237\x0\x46\x1\x5");

NOTE:

I use a CComBSTR so that I don't have to free any BSTR manually.
To specify an ASCII character in a string literal in C++ you have to prepend the ASCII code with "\x". Once you start specifying an ASCII character in the string literal, specify all characters in ASCII, else you will get compile or worse, runtime errors.
If you omit the "L" in front of the string literal you will get a C2022 compile error (in Visual C++ 2005 at least).
The ANSI code of \x237 is the diameter (phi) symbol. The ANSI code \x46 is the "." in 0.15. The rest are the Dec values (from the link provided) for "0", "1" and "5".

Conclusion

So how long has it been since you used the extended ASCII table? Its been so long for me, I don't even remember when I last used them. Glad I remembered how to!

"Google's new look" is actually "Jazz"

2010-04-16T17:05:00.000-05:00

If you read my previous post (http://ossandcad.blogspot.com/2010/04/googles-new-look.html) and found it "new" then I guess we both are late to the game. Search Engine Land already reported this new interface back in November. Thanks to the blog "Google Operating System" for the link.

I promise, next time I will only post relevant (to my blog that is) articles.

Google's new look

2010-04-08T00:50:00.003-05:00

Sorry if this post is not relevant to my regular topics but I just couldn't resist.

Is this Google's new look? Or is this some experiment that they are running that I am seeing?

On a more related note (to my blog that is) I am currently updating a project for a fixed backend DLL for the Pantheios logger (http://www.pantheios.org) that I will upload to my Google Code project soon (i.e. at http://ossandcad.googlecode.com). Will post about that as soon as possible.

Update April 9 2010: I am currently in New Jersey and don't see the modified Google search page (that I saw from Redmond). So obviously no dramatic changes by Google. Probably just some experiment that they are running that "I" happen to be a "part" of.

CEEFIT: I miss you

2009-10-21T17:30:00.009-05:00

I first noticed on Sep 24th that the web-site that hosts the C++ implementation of FIT (CEEFIT) was gone. I get a "DNS Error. Cannot find server" error for the URL http://ceefit.woldrich.com/. Even http://www.woldrich.com/ is no longer found, with the same error might I add.

This is not good. Indicates that the company that hosted/developed CEEFIT is gone taking some of the documentation for CEEFIT with it. While the source code for CEEFIT is still available at http://sourceforge.net/projects/fit/files/, some of the implementation details that were key for me to customize various aspects of CEEFIT are no longer available. If you use any of the downloads that I provide through the "My Downloads" section, you have the necessary header files and libraries to use CEEFIT in your IntegratedTests. But you would need the original source code and documentation for any customizations.

I have emailed Dave (using an old email address I have, which unfortunately is part of the woldrich.com domain) and hope I will hear back from him. I have requested he upload the documentation for CEEFIT to sf.net and I am really, really hoping he grants wishes.

In the short term I am screwed, but fortunately there is an alternate implementation of FIT in C++ available through http://www.fitnesse.org/. I have briefly tried fitnesse and have found the requirements they place to use their library (that I learn their Wiki markup to create tests and the ability to run a HTTP server on my build machine to run the tests) quite burdensome. But if I am going to continue C++ development and want to run Integrated Tests, I guess I have no other choice. But this time, I will be careful enough to create a personal mirror of www.fitnesse.org for myself, in case this too disappears off the face of the world(wideweb).

But honestly this is one more of the reasons why I love open source. If CEEFIT was a closed source library and the company developing it, shut down, then I would definitely be screwed. Since I have the source for CEEFIT, I can continue to develop it (if I had the requisite skills, of course).

So does CEEFIT going AWOL affect you?

Did uninstalling SolidWorks delete half my hard drive?

2009-10-16T17:30:00.006-05:00

I recently had to re-install SolidWorks 2009 on my laptop. During the uninstall process I noticed that several of my programs in the "C:\Program Files" folder went missing. Now I am not the one to start pointing fingers just yet, but this episode completely freaked me out. I had SolidWorks installed under "C:\Program Files\SolidWorks Corp" so would be more than surprised if this was in fact an error on the part of the SolidWorks uninstaller, but at the time of uninstallation, my laptop was not being used and no other "application window" was open. I also rarely log on with administrative privileges on either my XP or Vista laptop, so pretty low chance I accidentally deleted these folders myself (if I was that insane). I also did the usual checks for viruses, spyware and other junk, in vain.

Oh well! That's life I guess.

But during the reinstallation process I realized a quirk in the SolidWorks installation. Does it make sense to put header files required for SolidWorks Add-in development under the "samples" directory? Well that's what SolidWorks has done. So if you are developing SolidWorks add-ins, don't forget to select the "Examples" option in the SolidWorks Installation Manager, during the installation. Else you will not have the headers (e.g. "amapp.h") that you need for VC++ Add-in development.

Who uses BRL-CAD? An Anonymous answer

2009-10-15T17:30:00.003-05:00

This post is more of a response to a comment I received on my previous post titled And the World's Oldest Source Code Repository is.... Since the commenter chose to remain anonymous, I had no way to respond other than to blog a new post. I will resume posting "useful" information with my next post.

Firstly, Thanks 'Anonymous' (I knew I should not allowed people to comment on my posts anonymously, but it encourages more commenting from what I can tell), for your very detailed answer. I wonder if you are one of the seemingly many contributors to the BRL-CAD source code.

I would have been happier if you were able to provide some links to sites or people who use BRL-CAD, but I think I may be able to find at least 1 contact inside the U.S. Army Research Laboratory (ARL) who could enlighten me further.

It has been a long time since I downloaded and tested the latest version of BRLCAD. I am hoping to be surprised by their user-friendliness though from their screenshots (mostly updated in Mar 2008), it still appears command-driven rather than menu-driven.

And the World's Oldest Source Code Repository is...

2009-09-25T18:00:00.007-05:00

Many years ago (actually in 2006), I had written about an Open Source CAD program known as BRL-CAD (note: the links to tutorials I had included in that post are no longer active and give a message "BRL-CAD became an open source project in December of 2004 and is no longer hosted on FTP.ARL.ARMY.MIL").

Well surprisingly BRL-CAD has been in the news for a while. Were you aware that according to Ohloh, BRL-CAD has the world's oldest open source repository? Can you believe that? The repository supposedly has been active since 1983.

Well if you thought that was interesting then check this. BRL-CAD was also a participating organization in the Google Summer of Code 2009 and had 3 student interns who worked on as many projects.

So the oldest CAD program is still being actively developed. That is interesting, but what I want to know is who is using BRL-CAD? I work for a CAD tools company and we have never been requested to even look at BRL-CAD as a possible CAD system to support. BRL-CAD's About page says that the U.S. Military is one of the clients. I have been on a Civilian installation of the U.S Army and have seen BRL-CAD installed on their lab computers. But none of the modelers were using it to deliver designs. So the question still stands - who is using BRL-CAD?

Do any of you have any experience with BRL-CAD at your work? Does anyone use BRL-CAD for anything? Let me know.

Which Free 3D CAD program would I suggest?

2009-08-21T19:00:00.007-05:00

A few months ago I received a comment on one of my posts, asking me which free 3D CAD program I would suggest. You can see my response here.

Answering JOE's (the commenter) request reminded me that I had posted a few articles in the past about Open Source CAD programs. Since then though I had pretty much given up searching for an open source CAD program that would provide at least a usable modeling tool (primarily because my initial search was futile).

But I did keep my eyes open a little bit and came across NaroCAD a few months ago. Having followed NaroCAD's feeds for that period I noticed that it is under quite active development. From the developer's blog "NaroCAD is an opensource CAD design tool written in C#/.NET and is built on top of proven OpenCascade library". In fact NaroCAD reached 1.0 milestone a few months ago and they even provide .NET bindings for OpenCascade (including IronPython).

In my comment, I had recommended to JOE to use Alibre Design Xpress, since it is free, and offers great capability at that price (check out Alibre's CEO's blog - they even have a sale on Alibre Design Standard at the time of this writing, Aug 18 2009). I have not experimented with NaroCAD myself but considering its infancy I am relatively certain that its capabilities don't match Alibre's.

If the fact that I have a blog titled "Open Source Software and CAD" and am recommending a non-open-source program to my readers, alarms you, then don't be. I simply am recommending what I think is feasible. Most CAD users are not programmers. They may be versatile in creating Mapkey Automation or Macro scripts but mostly simply care about how complete their 2D/3D tools are for modeling purposes. In my experience with open source, attempting to use a program which has not matured, would usually result in much frustration to users who are not adept at looking at source code to solve any problems they may have (this is not to taint NaroCAD itself, it may be a great program, but just to explain my reason for the recommendation).

If you feel upto it, I would suggest downloading NaroCAD and experimenting with it. I am relatively certain that you may need to download OpenCascade separately as the installer for NaroCAD does not seem large enough (15.6MB) to accommodate all of OpenCascade (175MB).

UPDATE (8/30/2009): I stand corrected. One (of the 3 contributors to their blog) of the developers of NaroCAD (ciplogic) left a comment (still visible below this post) that NaroCAD uses only a subset of OpenCascade, which means that the ~15 MB download of NaroCAD is really all you need. So what are you waiting for? Have you downloaded NaroCAD? I have.

SWX Batch mode Integrated Tests with CEEFIT

2009-07-24T17:00:00.020-05:00

If you have read any of my previous posts on Testing CAD Plugins, then you are aware of what I am trying to accomplish - an automated Integrated Test framework to test, at the very least, SolidWorks API Plugins. The following are some of the more relevant posts regarding Testing CAD Plugins:

Some of you have even downloaded the sample workspace "swbatch.zip" posted in one of the posts above (Batch mode SolidWorks). For convenience the following is the "swbatch.zip" file.

http://ossandcad.googlecode.com/files/swbatch.zip

If you prefer to download from the source, you can do so using the following link with your SVN client (e.g. TortoiseSVN (follow the instructions at http://code.google.com/p/ossandcad/source/checkout)):

https://ossandcad.googlecode.com/svn/trunk/swbatch

The Pursuit of "CAD Plugin Testingness"
With this post I continue my pursuit of an automated Integrated Test Framework, using CEEFIT and dare I say it, I have come quite close to achieving my goal (my wishlist of sub-goals not yet achieved are listed at the end of this post).

Download the IntegratedTests workspace
You can choose the zip format or access from SVN directly:

http://ossandcad.googlecode.com/files/swxbatch_ceefit_6_16_2009.zip

https://ossandcad.googlecode.com/svn/trunk/swxbatch_ceefit

The "swxbatch_ceefit" workspace is an extension of the "swxbatch" workspace. The main difference is the ability to load SolidWorks and using API and CEEFIT, pass it input from the CEEFIT tables and verify expected output as mentioned in the CEEFIT tables.

The solution is documented - but its my contention that nothing is ever documented enough - so if you need more information on how things work then leave a comment. I will put up another post that has more details.

Assumptions:

You have SolidWorks installed and are working with appropriate licenses
You may need to have the SolidWorks API SDK installed to write SolidWorks API-based code.
You have access to Visual Studio (at least 2005, as this solution is provided in that version). Later versions should work but I have not tested them out.

Wish list of sub-goals

Passing in only HTML file (with CEEFIT tables) at a time is supported. This is how CEEFIT works by default, but it is not easy to test CAD stuff with all data in one single table. I wish for a solution to this and will post if I am successful. But for now it works as intended.
Currently integration of CEEFIT-based solutions with Continuous Integration systems (e.g. CruiseControl.NET) is poor, as CEEFIT only puts out HTML files and at least CruiseControl.NET does not merge HTML output as part of its build log, which is a bummer as "true" integration would help us identify a failure, location and cause, which this current framework does not do. I wish to write out the output of CEEFIT as XML (at least) so that it can be integrated into build systems. (To be honest, FIT and thereby CEEFIT profess to be tools that enhances customer interaction with systems in development, so HTML works best, but for developers HTML is difficult to incorporate into their workflow).
The provided workspace is good only for SolidWorks. I wish for a solution that allows interaction with various CAD systems, through their individual API, and tests my plugin application with all of them.

Notes and Tips:

The workspace, when run, starts SolidWorks in background (aka batch mode) by using a SolidWorks API, which simply hides the SolidWorks window.
```
swApp->put_Visible(FALSE)
```
If you want to make SolidWorks visible during its batch operations, then change the FALSE to TRUE and rerun. SolidWorks starts up and you can see all API actions play out like a movie. I should say it is almost as fun to watch as a video on Youtube.
I have used a global variable "swApp" as I don't know how else to pass variables in to the CEEFIT run test classes. While not a big problem, I hate global variables as they make testing otherwise hard to do.
Please visit the home page for this and other projects: http://ossandcad.googlecode.com for more information. I will try to update those pages soon and as regularly as possible.
For more information on CEEFIT you can read the short summary I have at http://ossandcad.blogspot.com/2008/05/protoolkit-solidworks-api-development.html or even visit the CEEFIT homepage at http://ceefit.woldrich.com/?page=Home. I should warn though that CEEFIT has not been updated for many years, but it works relatively well in its current stage. Hopefully enough of us use it to get the original author dave@woldrich.com to continue development.

If you have downloaded "swxbatch.zip" to develop SolidWorks plugin applications (or Addins) then I sure that this workspace will be very useful to you. Let me know if you do or don't. Comments and suggestions are most welcome and will be responded to, so feel free to communicate your needs.

New "My Downloads" Section

2009-07-03T11:54:00.011-05:00

First, thanks to everyone who downloaded the workspaces that I had uploaded to this blog (using http://www.box.net). I hope you found them useful.

Previously you could only find the uploaded workspaces by going to the individual posts. After noticing that these workspaces were being downloaded many times a week, I wanted to make it simpler for you, my readers, to find and download these workspaces.

I have added a "My Downloads" section, on the left sidebar (at the time of this posting, just below the "Older posts of mine" section) that links the relevant downloads. This will be a permanent fixture on each blog post page.

If you notice, these workspaces are being hosted on Google Code at http://ossandcad.googlecode.com which is my new repository for storing and sharing my CAD-API-based plugins and applications.

At the time of writing this post the following workspaces are made available on http://ossandcad.googlecode.com:

Pro/Toolkit + Visual Studio 2005 Workspace (http://ossandcad.googlecode.com/files/ProToolkitVisualCpp.zip)
SolidWorks Batch mode using SolidWorks API+COM (http://ossandcad.googlecode.com/files/swbatch.zip)
SWX+CEEFIT Integrated Test Workspace (http://ossandcad.googlecode.com/files/swxbatch_ceefit_6_16_2009.zip)

Comments, suggestions most welcome.

New Google Code project to accompany this blog

2009-07-02T17:00:00.011-05:00

Thanks to all of you who have downloaded the various zips from my blog. I was using www.box.net to store and share my files. While box.net was sufficient, it was getting difficult to track usage and download rate, since I was only using the free version.

To solve that problem and to find a simpler method to share my code, using a source code repository I have created a Google Code project. You can find my project at http://ossandcad.googlecode.com. I have added an introduction and some Wiki pages and some files for download.

The following files are available for download:

http://ossandcad.googlecode.com/files/swbatch.zip
http://ossandcad.googlecode.com/files/ProToolkitVisualCpp.zip
http://ossandcad.googlecode.com/files/swxbatch_ceefit_6_16_2009.zip -If you wondering what this is, then you have two options - wait for my blog post detailing how to use CEEFIT with SolidWorks API to run IntegratedTests - or - you could download and start working with the source code right away.

The following Wiki pages are also available (but mostly duplicating content originally posted on this blog)

http://code.google.com/p/ossandcad/wiki/SwxBatch

The biggest advantage of this for users is that you could download/browse my source code directly from SVN from http://code.google.com/p/ossandcad/source/browse/#svn/trunk. For me the biggest advantage is the ability to track usage using Google Analytics.

Comments/suggestions most welcome.

Unlocking Pro/TK Applications - Blog Referral

2009-05-19T08:00:00.006-05:00

In one of previous posts titled "License needed to run my Pro/Toolkit add-ins" I received a comment requesting help using protk_unclock.exe to unlock the Pro/TK application provided in the same post. (For sake of convenience the following is the zip of the source for Pro/TK application)

http://ossandcad.googlecode.com/files/ProToolkitVisualCpp.zip

As an answer to the question posed in that comment, I refer you to a post by my colleague, Amar Junankar, on his blog at http://cadinterface.blogspot.com/2009/05/unlocking-protoolkit-application.html. Amar has posted solutions for both developers and non-developers.

Welcome to the blogging world Amar.

MbUnit + AutoCAD = Unit testing for CAD Plugins

2009-04-07T21:00:00.002-05:00

If you follow my blog, you know that I develop CAD plug-ins in both .NET and C++. And in various posts of mine I have written about the difficulty of writing unit tests for these CAD plug-ins. The following are some of my more relevant posts regarding this topic.

My usual solution was to avoid unit testing these CAD plugins and simply write integrated tests for them. The last post mentioned above (Writing CEEFIT class like a regular C++ class) specifically shows a sample CEEFIT (Framework for Integrated Test for C/C++) class that enables integrated testing using SWX (I will post the complete workspace to do this soon).

But imagine my surprise when I read the following post about the release of MbUnit v3.0.5 - http://weblogs.asp.net/astopford/archive/2009/04/02/mbunit-3-rtm.aspx. The below text is an excerpt from that post (bold and italics are my addition):

Gallio provides MbUnit with the runner infrastructure and the list of supported runners is amazing, like MbUnit v2 you can still run MbUnit v3 in MSBuild, NAnt, TD.Net, CruiseControl, commandline (much more ehanched in v3) and GUI (also vastly enhanced in v3) but now tools such as TeamCity, VSTS, Resharper, Powershell, NCover, TypeMock and even AutoCAD.

That last word really caught my attention. What is this? Unit test support for CAD system plug-ins? That is so awesome it is beyond belief. A Google search for "AutoCAD MbUnit" gave more information via http://blog.bits-in-motion.com/2008/11/announcing-gallio-and-mbunit-v305.html. An excerpt:

AutoCAD Integration
Mike Sandberg has added support for testing AutoCAD plugins.
It turns out that AutoCAD has a managed extensibility model so you can create your own plugins using .Net and the ObjectARX toolkit. Unfortunately it is somewhat difficult to write unit tests for plugins becuase they must run within the main UI thread of AutoCAD.
The AutoCAD integration for Gallio works by loading a shim into the AutoCAD application from which it can launch tests. To enable this integration, specify the "AutoCAD" runner type to the Echo, Icarus, MSBuild, NAnt or PowerShell runners.
For example:

Gallio.Echo.exe MyTestAssembly.dll /r:AutoCAD [other options...]

AutoCAD integration is not yet available from within the IDE. We will be working to improve this use case in the future.

OK. This definitely is promising. The post provides usage scenario, and although low on details on how this is achieved beyond saying "loading a shim", it is exactly what we CAD developers need.

To learn more on how MbUnit developers solved this problem, I turned to the source code available at http://mb-unit.googlecode.com/svn/trunk/v3/src/Extensions/AutoCAD. From first glances it looks as though the shim can connect or load (via the "acad.exe" file) AutoCAD. The shim finds the path to "acad.exe" via the registry key

"HKEY_CURRENT_USER\Software\Autodesk\DWGCommon\shellex\Apps\{F29F85E0-4FF9-1068-AB91-08002B27B3D9}:AutoCAD".

It then determines if your plugin is loaded and if yes, sends commands to it using a TestDriver (AcadTestDriver).

What I found even more intriguing was the description of the problem that MbUnit developers intended to solve i.e. "difficulty of running unit tests as they run in the main UI thread of AutoCAD ". As I have contended, this is an universal problem for CAD developers. Replace AutoCAD with SolidWorks and the posts that I list above were intended to solve this very problem, although with a hack of a solution, but still following the same lines of thought. The CEEFIT workspace that I work with, loads SolidWorks in the background and using COM, connects to the running instance and then executes SWX-API-based tests. I let CEEFIT be the TestDriver and validate my output. The MbUnit framework has packaged idea this in beautiful .NET code.

This brings up the possibility that since SolidWorks plugins can also be .NET based, would replacing AutoCAD connection commands with SolidWorks connection commands in MbUnit's framework, allow loading the shim into SolidWorks and run unit tests against SolidWorks. I will be exploring this possiblity in the coming weeks/months, as time permits.

Do you develop AutoCAD plugins? Is this new functionality of MbUnit useful to you? Comments welcome.

SolidWorks API - In-process or Global methods - Which to use?

2009-03-02T02:00:00.001-06:00

Two SWX API to rule them (or is it 'Two SWX API to confuse us'?)
Did you know that SolidWorks (SWX) provides two distinct (yet confusingly similar) interfaces to 'get' or 'set' arrays through its API? Well it does. I recently installed SWX 2009 SP 2.0 (I know, I know - this release has been out for a while, but I never needed the newer features) - but I upgraded from SWX 2007 SP 0.0 when I ran into some vexing problem with the SWX API and hoping that it was an SWX bug, decided to try their newest version. Turns out the problem were me and my limited knowledge of these two API interfaces.

The one advantage of installing SWX 2009 was the updated API documentation. The 2007 API documentation did not contain a page titled "In-process methods", which the 2009 version does. The following is an excerpt from that SWX 2009 API page (apihelp.chm) (italics are my addition) (note to lawyers: if it is not legal to publish portions of the SWX help documentation, please leave a comment and I will remove the appropriate sections)

In-process Methods

The SolidWorks API provides two types of methods for interfaces that get or set arrays:

in-process

global

For example, IView contains these methods:

IView::IGetCThreads (in-process)

IView::GetCThreads (global)

Both types of methods perform the same work, but each is more or less appropriate for a given language and application.
In-process methods typically begin with the letter I and get or set pointers to arrays that only unmanaged C++ applications can handle. The in-process companion methods (i.e., similarly named methods that do not begin with the letter I) are more globally useful both inside a process and across processes and return predictable results for all of the SolidWorks supported languages.
In VBA, VB6, VB.NET, C#, and C++/CLI (also called managed C++), global methods typically get or set a VARIANT or object that the programmer can iterate as an array. In unmanaged C++, these methods get or set a pointer to a Dispatch object that should be cast as a SafeDISPATCHArray. (SafeDISPATCHArray is a VARIANT helper class defined in a template class, which is available on the API Support website.)

Q. To chose or not to chose
So how do you decide which interface to use? Does it even matter?
A. The answer to the 2nd question 'does it even matter' is - simply - YES IT DOES MATTER.

To answer the 1st question 'how do you decide which interface to use' - consider the following:

you are building a DLL Add-in to SWX,

AND
you plan to only load that DLL through SWX

THEN
you can comfortably use the "in-process method".

But if

you are building an EXE that loads SWX through COM

AND
loads your SWX Add-in DLL (i.e. instantiates classes from the Add-in DLL in the EXE), allowing calls from the Add-in DLL to go to SWX

THEN
you need to use the "global method" in

BOTH
the COM+EXE and Add-in DLL.

AND
LUCKILY YOU CAN STILL LOAD THE DLL ADD-IN DIRECTLY INTO SWX (doesn't that sound ideal?)

So how do you work this "global method"?
If you are like me and have little experience with COM, DISPATCH and VARIANTS then fear not because SolidWorks is gracious enough to provide us with a C++ template to simplify our lives. The files you need are hosted at http://files.solidworks.com/API/Examples/00000/0100s/0126/Example.htm. Simply download the zip file and include the "smartvars.h" file in your solution. The zip file also contains a sample in the file "usage.cpp", but for the sake of completness let me provide you with an example of my own:

VARIANT vxform;
LPSKETCH pSketch;
...
... // code to InsertSketch() so that pSketch is a valid pointer
...
pSketch->get_ModelToSketchXform(&vxform);
SafeDoubleArray varDimArr(vxform);
wofstream wfs;
wfs.open(L"dimension_data_swx3dexpextrusion.txt");
for( int i = 0 ; i < 13 ; i ++ ) {
wfs << "\nXFormData at\t" << i << "\t=\t" << varDimArr[i];
}
wfs.close();

CONCLUSION
SolidWorks API while easy to work with have a few surprises - though in this case the missing documentation would have spoiled the surprise for me in the 2007 version. So all in all, I am able to run batch-mode integration test using the combination of CEEFIT and "global methods" to access array data from SolidWorks.

Writing CEEFIT class like a regular C++ class

2009-02-02T01:17:00.002-06:00

FIT / CEEFIT?
If you need to write integrated tests that can take a table specifying input data and expected output data, and run the tests in a batch, then you should consider Fit: Framework for Integrated Test. If you develop applications with C++, then look to CEEFIT to satisfy your FIT needs.

CEEFIT is well documented, flexible and an excellent integrated test framework. In most cases you can use the Macro method to create your test-classes, but CEEFIT also provides a way to create test-classes manually from scratch. This second 'manually from scratch' method is what this post talks about.

Why would you want to write CEEFIT classes from scratch?
Well one reason for me was to ensure that I could still use Doxygen to document the classes and their methods and parameters i.e. make the code-documentation doxygen-visible. I have not been able to figure out how to have the documentation be doxygen visible when using the macros.

How to write CEEFIT class from scratch?
The example posted on CEEFIT's website is excellent and provides everything you need, but I found it a little too much. I simply wanted to write a class that inherits from COLUMNFIXTURE that looks like a regular C++ class - I did not want to mess with TABLE or DoRows(). Turned out to be very simple to do and here it is:

TestSWX.h
namespace swx_ceefit {
/** A CEEFIT class created from scratch without macros to test batch-mode processing of SWX API cases.
        \author GRI
        \date Dec 1 2008
    */
    class TestSWX :
        public CEEFIT::COLUMNFIXTURE
    {
    public:
        inline ceefit_init_spec TestSWX();
        inline virtual ceefit_dtor_spec ~TestSWX();
    private:
         ceefit_init_spec TestSWX(const TestSWX&);
         TestSWX& ceefit_init_spec operator=(const TestSWX&);
        /** fit_var
        */
        CEEFIT::STRING m_sldprt_name;
        /** fit_test
        */
        double ceefit_call_spec nos_feats();
        /** where is this executable executing from?
        */
        void ExecutingPath();
        /** Get the full path to the input file i.e. the *.sldprt file
            \author GRI
            \date Jan 8 2009
        */
        void GetFullPath(std::wstring & wsFullPath);
    };
}

TestSWX.cpp
CComPtr swApp;

namespace swx_ceefit
{
    ceefit_init_spec TestSWX::TestSWX()
    {
        RegisterCeefitField(this, "sldprt_name", m_sldprt_name);
        RegisterCeefitTest(this, "nos_feats", &TestSWX::nos_feats);

        //cout << endl << "constructing";
    }

    ceefit_dtor_spec TestSWX::~TestSWX() {
        //cout << endl << "destructing";
    }

    double ceefit_call_spec TestSWX::nos_feats() {
        ExecutingPath();
        wstring wsFullPath;
        GetFullPath(wsFullPath);
        if( swApp ) {
            IModelDoc* swModel = NULL;
            if( swApp->put_Visible(FALSE) == S_OK ) {
                if( swApp->DocumentVisible(FALSE, swDocPART) == S_OK ) {
                    //wcout << "\nfull path in nos_feats = " << wsFullPath.c_str() << endl;
                    CComBSTR sFileName(wsFullPath.c_str());
                    CComBSTR sDefaultConfiguration(L"Default");
                    long fileerror;
                    if( swApp->IOpenDocSilent(sFileName.m_str, swDocPART, &fileerror, &swModel) == S_OK ) {
                        if( swModel != NULL ) {
                            IPartDoc *part;
                            HRESULT hres = swModel->QueryInterface(IID_IPartDoc, (LPVOID *)&part);
                            if( swModel->put_Visible(FALSE) == S_OK ) {
                                CComPtr swfeat;
                                if( part->IFirstFeature(&swfeat) == S_OK ) {
                                    CComBSTR name;
                                    swfeat->get_Name(&name);

                                    wcout << endl << "1st feat name = " << name.m_str;
                                    swModel->Quit();
                                } else wcout << endl << "no first feature";
                            } else wcout << endl << "swModel still visible";
                        }
                        else {
                            wcout << endl << "swModel = NULL with fileerror = " << fileerror;
                        }
                    } else wcout << endl << "open doc not silent";
                } else wcout << endl << "document still visible";
            }
        }
        else wcout << endl << "ERROR: swApp = NULL" << "\tfile\t=\t" << __FILE__ << "\tline\t=\t" << __LINE__;
        VARIANT_BOOL ret;
        swApp->CloseAllDocuments(TRUE, &ret);
        return 1;
    }

    void TestSWX::ExecutingPath() {
        wchar_t sExecPath[MAX_PATH];
        GetModuleFileName(NULL, sExecPath, MAX_PATH);
        //wcout << endl << "executable = " << sExecPath;
    }

    void TestSWX::GetFullPath(wstring & wsFullPath) {
        wchar_t cFullPath[MAX_PATH] = TEXT("");
        LPTSTR lpszFilePart = NULL;
        GetFullPathName(m_sldprt_name.GetBuffer(), MAX_PATH, cFullPath, & lpszFilePart);
        //wcout << endl << "full path = " << cFullPath;
        wsFullPath = cFullPath;
    }

    static REGISTERFIXTURECLASS< TestSWX > FatTableFixtureRegistration("swx_ceefit::TestSWX", "AKA_TESTSWX");

Conclusion
If you are wondering why this class is called TestSWX (SWX = short for SolidWorks), then consider this: using the solution from a previous post of mine "Batch mode SolidWorks" we can start SolidWorks without GUI and using the above CEEFIT class, call SolidWorks API and run your integrated tests. But that my readers is possibly a separate post.

Office 2003 Addin using Visual Studio Add-in (Extensibility) Project

2008-12-04T21:41:00.001-06:00

A while back I had to write an add-in to Microsoft Office 2003 for a client and ran into numerous issues during both the development and the deployment of the add-in. Thought I should post it here in hopes that someone may find it useful.

I use Visual Studio 2005 Standard (I know, I know Visual Studio 2008 is out but I develop Pro/Toolkit and SolidWorks API applications too and am not sure if the upgrade is a simple recompile and link, so have not upgraded.), so in order to develop Microsoft Office 2003 Add-ins I had two options:

Use the Visual Studio Add-in Template under the "Extensibility" Project Type.
Use Visual Studio 2005 Tools for Microsoft Office 2003 (VSTO)

There is a good comparison of these two choices at CodeProject. I have a few additional points to note here that may influence your choice:

Using Visual Studio Add-in Template

DEVELOPMENT: Writing code for the add-in gets very clunky. The following is a sample excerpt:
using Microsoft.Office.Core;
using nsWord = Microsoft.Office.Interop.Word;

nsWord.ApplicationClass office_app;

public void OnConnection(object application, Extensibility.ext_ConnectMode connectMode, object addInInst, ref System.Array custom)
        {
            applicationObject = application;
            addInInstance = addInInst;
            if (connectMode != Extensibility.ext_ConnectMode.ext_cm_Startup)
            {
                OnStartupComplete(ref custom);
            }
            /// which office app is "application"
            ///
            if (application is nsWord.Application)
            {
                office_app = (nsWord.ApplicationClass)application;
                //if (logger.IsInfoEnabled) { logger.Info("host app is Word"); }
            }
        }

As can be seen from the last few lines, to determine the Office Application that the add-in is loaded in is an equivalence test (using if-else or switch-case or some similar). I know this is not a good solution, but I don't have anything better (if someone has a better suggestion I would really appreciate the tip.

Even if I got beyond that I am still casting the 'object application' to 'Microsoft.Office.Interop.Word'. I guess I could have used inheritance to pass 'application' to a sub-class that would deal with the specific Office Application, but I was surprised to find that you could not simply query for the Office App Type.
DEPLOYMENT: Deploying the Shared Add-in requires a bunch of updates from Microsoft that have to be applied to the target PC:

Microsoft .NET Framework (I personally installed 2.0 though latest versions should also work)
KB 908002 (http://support.microsoft.com/kb/908002) - Download and execute the EXE file. The EXE download actually contains 3 files all of which has to be applied to the target system in the following order:

lockbackRegKey.msi
office2003-kb907417sfxcab-ENU.exe
extensibilityMSM.msi

Office 2003 Primary Interop Assemblies (http://www.microsoft.com/downloads/details.aspx?FamilyId=3C9A983A-AC14-4125-8BA0-D36D67E0F4AD&displaylang=en) - The download (an EXE file) contains an MSI file that has to be run on target system.

As far as I can tell KB 908002 and the Office 2003 Primary Interop Assemblies cannot be uninstalled.

I have not had a chance to write code with VSTO, but considering that it was designed for such applications, I am assuming that you will not have most of the weirdness stated here. If you have Visual Studio 2005 Professional, then you can download VSTO here [3]. You can search on Microsoft's Download center for respective versions of VSTO for VS 2008 (for Microsoft Office 2003/2007).

Acknowledgements:

License needed to run my Pro/Toolkit add-ins

2008-09-18T12:16:00.004-05:00

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

2008-09-08T23:25:00.000-05:00

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:

Current directory

< Pro/ENGINEER >/< MACHINE >text

< 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:

On install append the add-ins registration information to the protk.dat file in < Pro/ENGINEER >\text
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.