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

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.

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

2008-05-05T10:03:00.001-05:00

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)

2008-05-02T17:15:00.000-05:00

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.

Batch mode SolidWorks

2008-04-10T11:04:00.049-05:00

I saw a post on Google Groups where a user had posted a question (2 years ago) asking how one could open SolidWorks silently viz. no GUI and use SolidWorks APIs to open a part but there was no answer that I could find right of.

In the same vein as my previous post titled "Batch mode Pro/Engineer" I tried to create a similar workspace for SolidWorks that executes SolidWorks with no GUI but still uses the SolidWorks API to load and query parts or assemblies. Fortunately SolidWorks API makes it much easier to do this as compared to Pro/Toolkit. After a little experimentation I came up with the following solution. The solution was created in Visual Studio 2005 using Visual C++. Click on the following zip file to download the solution.

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

Setup of Solution
Simply create a new "Win32 Console Application" project in Visual Studio 2005.

Edit the project's properties and add the following directory to the "Additional Include Directories" under "Configuration Properties"->C/C++->General:

"c:\program files\solidworks\samples\appcomm\win32\"

You should have a "cpp" file named swbatch.cpp (or something similar depending on the name you selected for the console application). Open that file and add the following code to it above the main() (or _tmain()) function.

#include "iostream"
#include "objbase.h"
#include "atlbase.h"

//Import the SolidWorks type library
#import "C:\Program Files\SolidWorks\sldworks.tlb" raw_interfaces_only, raw_native_types, no_namespace, named_guids
//Import the SolidWorks constant type library
#import "C:\Program Files\SolidWorks\swconst.tlb" raw_interfaces_only, raw_native_types, no_namespace, named_guids

Then modify your main() (or _tmain()) function to look like the source code included in the zip file. I apologize for not posting the code directly into the body of this post, but Blogger was messing up the formatting.

Make the following changes to the code in main():

Make sure you have a SLDPRT file in the location stated above instead of "C:\\swbatch\\Debug\\camtest.sldprt". Change the path to which sFileName points to, to coincide with your true path.

Build the solution and execute it. The console application will startup and silently load SolidWorks. If you have Windows Task Manager open then you will see SLDWORKS.exe running. If the SLDPRT is found in the right location, then the code above reads the SLDPRT and throws a MessageBox with the name of the first feature of the SLDPRT, which in this case is "Annotations". After the program exits, SolidWorks exits too.

Note:
Please keep in mind the following points about the code in main() in the zip file:

I first tried to use OpenDoc6 as follows:

swApp->OpenDoc6(L"C:\\cygwin\\home\\ganesh\\downloads\\imagecom\\batch\\camtest.sldprt", swDocPART, swOpenDocOptions_Silent, L"Default", &fileerror, &filewarning, &swModel)

By doing that, SolidWorks started up with its GUI and then tried to load the model, which was not what we wanted. Next I tried an old API OpenDocSilent() as follows:

swApp->IOpenDocSilent(sFileName, swDocPART, &fileerror, &swModel)

This had the required effect of opening SolidWorks silently and loading the model in it.
The other big problem I noticed was: IF YOU LOAD A READ-ONLY SLDPRT INTO SOLIDWORKS USING OPENDOCSILENT(), FOR SOME REASON SOLIDWORKS STARTS UP WITH GUI. The only solution I have for this at the present is to not load read-only parts or assemblies.

If you found this article useful, please let me know. It helps me identify which posts, my readers prefer.

UPDATE: THE POST WAS UPDATED ON AUGUST 3RD 2009 TO REPLACE THE DOWNLOAD LINK FOR SWBATCH.ZIP. PREVIOUSLY SWBATCH.ZIP WAS SERVED FROM BOX.NET. IT IS NOT BEING SERVED FROM GOOGLECODE.

Batch mode Pro/Engineer

2008-04-04T18:27:00.017-05:00

Have any of you tried to start Pro/Engineer in batch mode? I found the following suggestion in Pro/Toolkit documentation tkuse.pdf:

"To ensure that the Pro/ENGINEER main Graphics Window and Message Window are not displayed, you should use either the command-line option -g:no_graphics (or the configuration file option “graphics NO_GRAPHICS”) to turn off the Pro/ENGINEER graphics."

So to start Pro/Engineer in batch mode with no graphics try the following with Pro/Engineer Wildfire 3.0. To execute this simply open a command prompt using Windows Start->Run-> Enter "cmd", press OK, enter the following into the command prompt and enter enter.

"C:\Program Files\proeWildfire 3.0\bin\proe.exe" -g:no_graphics

To verify if Pro/Engineer started with no GUI simply open Task Manager and look for xtop.exe, which is Pro/Engineer's executable. But since no processing is happening, xtop.exe will quit after a few seconds.

Why is this important?
Well if you wanted to perform the same operations on numerous files (part or assembly), then theoretically you could execute Pro/Engineer without GUI from the directory where you have a Pro/Toolkit application installed with a protk.dat registry file and Pro/Engineer will load that Pro/Toolkit application. The application can then perform its functions without needing user interaction. For an example see this link where they use this method but instead of a Pro/Toolkit application they use the "trail" files to script the batch processing. Something similar can be duplicated with a Pro/Toolkit application.

Why do I mention this?
As a developer of Pro/Toolkit applications it is very important for me to able to test my program thoroughly with as much automation as possible. By using the batch mode without GUI provided with Pro/Engineer I can create a workspace that tests my application using numerous combinations of input and output without user interaction.

I plan to write on topics related to integrated test frameworks for Pro/Toolkit applications and batch mode could become an important part of that. Keep following my blog for similar posts.

HOWTO: Example Pro/Toolkit Application using Visual Studio 2005

2008-03-26T02:05:00.057-05:00

In my previous post titled "Example ProTookit Application using Visual Studio 2005" I received a comment asking to explain how I created the sample workspace (Pro/Toolkit Application using Visual C++ 2005) which can be downloaded by clicking the file below:

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

I should point out that the workspace that is attached above, while it is currently in Visual Studio 2005 format, came initially from Visual Studio 2002 (or known as Visual Studio.NET) and my colleagues and I regularly updated the workspace in current versions of Visual Studio.

In this post I try and explain the steps I used to create a sample workspace from scratch in Visual Studio 2005 for Pro/Toolkit applications. For more details (although with some mistakes some of which I will list in future posts) refer to "tkuse.pdf" in "C:\Program Files\proeWildfire 3.0\protoolkit".

I break the process down into following steps:

Creating the Visual Studio 2005 solution

The easiest method I know of to create a Pro/Toolkit Application in Visual Studio 2005 (that matches the above workspace) is to start with an Empty Project. Name it "proe" for example.

Add a file named "main.cpp".

Add the following code to "main.cpp"

#include <windows.h>

#include <protoolkit.h>
#include <procore.h>

/** Make sure to call ProToolkitMain passing the arguments passed into main
*/
extern "C" int main(int argc, char **argv)
{
ProToolkitMain(argc, argv);
return 0;
}

/** Required entry point for Pro/Toolkit
*/
extern "C" int user_initialize()
{
MessageBox(NULL, "Pro/Toolkit App", "proe", MB_OK);
return 0;
}

extern "C" void user_terminate()
{
return;
}

Change the "Configuration Type" to "Dynamic Library (.dll)".

Add the relevant include folders for Pro/Toolkit ("C:\Program Files\proeWildfire 3.0\protoolkit\includes";"C:\Program Files\proeWildfire 3.0\prodevelop\includes").

Add the following pre-processor definitions (WIN32;NDEBUG;_WINDOWS;_USRDLL;PROE_PROJ_EXPORTS;PRO_MACHINE=29; PRO_OS=4;hypot=_hypot;MSB_LEFT;far=ptc_far;huge=p_huge;near=p_near;_X86_=1)

Make sure for the Runtime Library you are using "Multi-threaded DLL (/MD)" or the "Multi-threaded Debug DLL (/MDd)" based on whether you are using "Release" or "Debug" configuration respectively.

Make sure that the "Treat wchar_t as Built-in Type" is set to "No (/Zc:wchar_t-)".

Add the relevant Pro/Toolkit and Pro/Develop library folders ("C:\Program Files\proeWildfire 3.0\prodevelop\i486_nt\obj";"C:\Program Files\proeWildfire 3.0\protoolkit\i486_nt\obj").

Add the "Additional Dependencies" (wsock32.lib mpr.lib prodev_dllmd.lib protk_dllmd.lib psapi.lib)

Do a Rebuild and make sure you have a DLL named "proe.dll" in a sub-folder named Debug or Release depending on your build configuration.

Creating the Pro/Toolkit application files and message files

Pro/Engineer loads Pro/Toolkit applications using a registration file named "protk.dat" in the Debug AND Release folder. You need to create a protk.dat file for the Pro/Toolkit DLL that you created using the workspace above. While developing and testing the Pro/Toolkit application I use the following "protk.dat":

NAME proe
EXEC_FILE proe1.dll
TEXT_DIR ..\text
STARTUP DLL
allow_stop TRUE
revision Wildfire
END

The "protk.dat" is pretty easy to understand although it would have helped if Pro/Engineer used a more standard method such as the Windows Registry (although that may not work since Pro/Engineer is multi-platform). The main variables you need to be aware of are:

TEXT_DIR - The value for this variable is "..\text". This means you need to create a sub-folder named "text" under your main folder. In the "text" folder create a text file named "menu.txt". The "text" folder and the text file "menu.txt" (the name can be changed but I don't delve into that in this post) are Pro/Engineer's bizarre method to enable localization. The "menu.txt" file looks something like the following:

USER %0s
%0s
#
#
MenuLabel
Menu
#
#
PushButton
PushButton
#
#

It simply lists the label that is seen by the Pro/Toolkit application and its corresponding value. Most Visual C++ developers use either a String Table or other sort of Resource. If you think this is weird, I think it may have something to do with Pro/Engineer supporting multiple Operating Systems.

STARTUP - For the example provided the type is "DLL".

Execute Pro/Engineer and load the Pro/Toolkit Application

While developing and testing your Pro/Toolkit application I use the following method:

Create a shortcut to "C:\Program Files\proeWildfire 3.0\bin\proe.exe" in your Pro/Toolkit's "Debug" or "Release" folder.
Make sure the "Start in" text box for this shortcut remains empty which means that this shortcut will start Pro/Engineer in the current folder and will automatically load the DLL specified in protk.dat located in the same folder.
Double click the shortcut you created to run Pro/Engineer. If you get a message box with the text "Pro/Toolkit App" then IT WORKED. REJOICE.

If the method in the above post did not work for you, you can also download the ZIP file I have provided and try that out. If you need more help, post a comment and I will try to provide more information.

Example ProTookit Application using Visual Studio 2005

2008-02-14T18:41:00.011-06:00

PTC has been offering an Application Programming Interface (API) for Pro/Engineer for many years now and I have seen an article or two or three online that shows you how to develop Pro/Toolkit applications using Visual C++. These are very useful and if you navigate to the bottom of the page on article three then you will find a few zip files that you can download and start working with Visual C++ and Pro/Toolkit quickly. There is even a site that sells you tutorials on how to develop Pro/Toolkit applications. Of course I have never purchased any such tutorials so am unable to recommend them.

Interestingly very little outside help is available on developing Pro/Toolkit Applications using Visual C++. Simply Googling for Pro/Toolkit help is of very very little help. So what is a Pro/Toolkit developer to do?

In an effort to help other Pro/Toolkit developers who are using Visual C++ 2005 I have attached a zipped workspace created in Visual Studio 2005. This zipped workspace allows you to create a DLL that creates a Menu in the Pro/Engineer interface. Please use this workspace as a starting point - it is not by no means the perfect workspace (for example I currently put the menu.txt in two locations - which is not the most efficient way to do it). This workspace was created and donated by a colleague of mine, Amar Junankar (although I had created a similar workspace and have kept it updated for many years).

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

If you notice carefully in the workspace (after unzipping) in both the "debug" and "release" sub-folders there is a batch file named "Start_ProE_Here.bat". What this batch file does is start Pro/Engineer (default location of "C:\Program Files\proeWildfire 3.0\bin\proe.exe") from the "debug" or "release" (viz. current) sub-folder. This ensures that the protk.dat (which Pro/Engineer uses to register Pro/Toolkit applications) is loaded on startup of Pro/Engineer thus enabling our Pro/Toolkit application. Of course before starting this batch file, please do a build of both debug and release configurations.

As a side note: In my next post I will add to this workspace the necessary lines of code that will allow a developer to call .NET assemblies from within the Pro/Toolkit Application.

If you need any help please post a comment and I will try to help as much as I can.

.NET in Pro/Toolkit

2008-02-04T11:06:00.000-06:00

Summary: Can we use .NET to develop Pro/Toolkit applications for Pro/Engineer?

I have seen numerous articles providing tutorials (heres one and another one) on how to develop Pro/Toolkit applications using Visual C++ (either 2003 or 2005). Now the articles refer to developing Pro/Toolkit applications using Visual C++.NET which I think is misleading since the .NET portion refers (I believe) to Managed Visual C++ code while the articles refer to Unmanaged Visual C++ code.

So this begs the question: how does one develop Pro/Toolkit applications using Visual C++.NET Managed Code and is this even possible?

The short answer is NO - YOU CANNOT DEVELOP Pro/Toolkit APPLICATIONS USING VISUAL C++.NET MANAGED CODE (or C# or Visual Basic.NET).

The long answer is PERHAPS - I found a product by ETRAGE LLC named ACI for Pro/Engineer that provides a COM wrapper around Pro/Toolkit functions. Using such a wrapper developers can code Pro/Toolkit applications using pure .NET languages. In fact the product page provides sample code in Visual Basic.NET. This is pretty nice, since if I were to replicate such functionality then I would need to create a DLL (since I could not find a DLL containing Pro/Toolkit functions for Pro/Engineer Wildfire 3.0) that exports the functions in the LIB and mentioned in the header files and then use that DLL in .NET through .NET's Platform Invoke - which is a lot of work - not difficult but a lot of work (major testing would be required). I will try this method out and if it works will post another article with a HowTo.

But suppose you wanted to merely call functions from .NET classes in your Pro/Toolkit application then there is a simple way to do so using the idea of exposing .NET objects through COM interface. This article on CodeProject provides a great tutorial on how to do just that. Of course you are still developing the Pro/Toolkit application using Visual C++ but now you can consume .NET objects easily.

An FYI though if you use the method suggested by the CodeProject article - there is a slight slowdown when you call the COM methods (I think the call to CoInitialize is what causes this problem) - so initialize and finalize the COM components once for your application instead of for each method call.

I will try and post a sample workspace with my next post that shows how to use .NET objects in Pro/Toolkit applications. If anyone has any comments or questions please provide them below I will do my best to answer them.

Register MMS protocol in Firefox

2008-01-31T23:37:00.000-06:00

Update: Surprisingly this post (originally posted in January 2005) still seems alive 3 years after my post. I should warn that I have not tried this method with Firefox versions later than 1.0 and have only tried it on Suse Linux Personal 9.1. If you need help please post a comment and I will try to help. I no longer use Suse and have since moved to Ubuntu (currently using Dapper LTS since I don't have time or need to update often) but will try to help as much as I can. Please see the comments on this post to see if someone has already tried to achieve what you want to.

MMS stands for Microsoft Media Services and as the Microsoft site says it is a proprietary streaming media protocol. This means that Internet Explorer (IE) has this protocol registered by default but Mozilla Firefox will need some tweaking before it lets you play mms:// streams.

I have tested this on Mozilla Firefox 1.0 (rpm version = MozillaFirefox-1.0-2.1) on Suse Linux Personal 9.1 and also Fedora Core 3. I believe this method will work on other versions of Mozilla Firefox and Linux OSs but have not tested them. Also the method suggested here is per user alone and not per install. I have included mplayer as the multimedia application that will play the mms:// stream. I assume that you have mplayer installed properly and able to play mms:// streams. You can try other media players but I have not tested others.

NOTE: Entering values/names/url's should be done without quote marks.

In the URL bar of Firefox type "about:config".
You need to create two new values as follows:

Right click in the Firefox main window, click on "New" and select "String".
In the text box that pops up type "network.protocol-handler.app.mms" for the preference name. Click OK.
For Value enter "/usr/local/bin/gmplayer". This is where my gmplayer is installed. If you have it in a different location, type that in for the value. To find where gmplayer is installed on your computer enter whereis gmplayer in a console. Enter the value that the "whereis" query outputs. Click OK.

Right click in the Firefox main window, click on "New" and select "Boolean".
In the text box that pops up type "network.protocol-handler.external.mms" for the preference name. Click OK.
For value enter "true". Click OK.

At the end of this process you should have these two new values (type mms in the filter text box in the about:config window)

- Preference name: network.protocol-handler.app.mms
Status: user set
Type: string
Value: /usr/local/bin/gmplayer

- Preference name: network.protocol-handler.external.mms
Status: user set
Type: boolean
Value: true

Now go to a site that provides mms:// streams and test. If this does not work, then I would suggest that you test to see if your default player can play the mms:// streams. Pass the URL of the mms:// stream to mplayer directly using the command line/GUI. If it plays then try a different profile in Mozilla Firefox and see if that works (you can create a new profile by using either the" firefox -P" or the firefox -ProfileManager" commands).

Use Runas in Windows XP for increased security

2006-10-27T18:37:00.001-05:00

Summary: Windows Administrators logged in as regular users needing to perform occasional administrative tasks can use Runas built into Windows XP. This post tells you how to manage files and folders in Windows Explorer using Runas.exe as Administrator while logged in as regular user.

I know, I know this post has nothing to do with Open Source or CAD, but in my defense I used this solution while fixing the problem in my previous post with 3ds Max. Runas is what I use since I am normally logged into my Samba domain as regular Domain user but still need to perform administration tasks. We all know that logging in to Windows as administrator causes the most problems - so I avoid it.

To test whether the changes I made to 3ds Max folders (license = "C:\C_Dilla\" and program folders = "C:\Program Files\3dsmax42\") solved the problem I was required to log in as Administrator, make changes, log off, log in as regular user, test 3ds Max - rinse and repeat as required numerous times.

Well with this simpler (compared to multiple log offs and log ins) process I was able to avoid that problem. Thanks to Microsoft Windows XP - Runas.

1. Log in as regular user.
2. Start Task Manager using Ctrl + Shift + Esc.
3. Find explorer.exe in Processes tab. Click on "End Process".
4. Go to Applications tab. Click "New task".
5. Enter "runas /user:administrator explorer.exe" without the quotes.

(Click image to enlarge)

6. Enter administrator password.
7. Voila. Windows Explorers start in administrator mode including the desktop and taskbar.
8. Once you are done playing with Windows Explorer and want your regular user's explorer, close the Task manager that you had opened in step 2.
9. Once again open Task Manager using Ctrl + Shift + Esc. This is to ensure that the Task Manager that opens up is running as administrator and not as regular user that opened up in step 2.
10. Find explorer.exe in Processes tab. Click on "End Process".
11. Go to Applications tab. Click "New task".
12. Enter "runas /user:[regular user] explorer.exe" without the quotes. Make sure you replace [regular user] with the username you are logged in as and know the password of.
13. Enter regular user's password. And Windows Explorer, desktop and taskbar will start as the regular user.

This process can get irritating after a while - especially if you have to enter the password numerous times. Try the following to save password (as long as your administrator password and your regular user password does not change).

runas /user:[regular user] /savecred explorer.exe

If the above does not work or you need more help leave me a comment. I will be more than happy to help.

Run 3ds Max as regular user

2006-10-27T17:55:00.000-05:00

Summary: Running 3ds Max 4 as regular user causes problems but as administrator it works fine. The following is my solution.

In my lab we are still running 3ds Max 4, which at time of post is 5 versions too old. But one problem that was nagging us (till date), and were never able to solve, was that 3DS would run fine as administrator but on a regular user account it would never startup and throw a [16.1.7] error. A quick Google search will pull the following solution from Autodesk's website. The basic solution to the problem is stated as follows:

Find folder "C:\C_Dilla". Make sure Hidden folders are visible. You can change this in Windows Explorer-> Tools -> Folder Options. The Autodesk page has the required screenshots for this.
Give your Users account Full Control to the "C:\C_Dilla" folder and sub-folders.

This definitely fixes the problem while starting 3ds Max. But we were still having major problems while closing 3ds for which I suggest following solution. It turns out that 3ds Max needs to write to the location where it was installed and some sub-folders [UI sub-folder in "\Program Files\3dsmax42\" to be precise].

[Disclaimer: This solution is actually a crappy workaround that shows how poorly some applications are developed in a manner that reduces security on a Windows PC].

Log in as Administrator to your Windows PC.
Open Windows Explorer.
Scroll down to your Program Files folder [most probably "C:\Program Files\" or "D:\Program Files\"] and expand it.
Find the "3dsmax42" folder. [Providing access only to the UI sub-folder was not sufficient. Don't know why.]
Right click on it and select Properties. Click on the Security tab.
Select the Users group and give Full Access to this group [and weep a little].
Log off and log on as regular user. Start 3ds Max and watch it open and close like it is supposed to.

I don't have access to the latest 3ds Max and don't know if they have fixed this problem. If yes then do let me know. And more importantly if this does not work for you then please leave me a comment and I will look into it.