Lesson 1: Licensing is part of Software Engineering

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

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

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

1. 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.
2. 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.
3. Customizable License Manager (preferably through API) AND
4. 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.
5. 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.

Will the real 'PHI' symbol please stand up?

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:

1. The "L" is to specify that this is Unicode.
2. The "\u" is to specify Unicode characters in literal strings
3. And as we saw as the answer to the first question, the "00D8" (thats ZeroZeroD8) is the PHI symbol
4. The trailing 0.15 is simply a size that SolidWorks Hole could have
5. 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

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!

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

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?

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.

New Google Code project to accompany this blog

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:

1. http://ossandcad.googlecode.com/files/swbatch.zip
2. http://ossandcad.googlecode.com/files/ProToolkitVisualCpp.zip
3. 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)

1. 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.

MbUnit + AutoCAD = Unit testing for CAD Plugins

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.

• Pro/Toolkit, SolidWorks API Development Tools (C# Episode)
  
• Pro/Toolkit, SolidWorks API Development Tools (C++ Episode)
  
• Writing CEEFIT class like a regular C++ class
  

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?

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:

• If 

1. you are building a DLL Add-in to SWX,
   
   AND 
   
   
2. you plan to only load that DLL through SWX
   
   THEN
    
3. you can comfortably use the "in-process method".

• But if

1. you are building an EXE that loads SWX through COM
   
   AND
    
2. 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
    
3. you need to use the "global method" in
   
   BOTH
    
4. the COM+EXE and Add-in DLL.
   
   AND
   
   
5. 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.

Batch mode SolidWorks

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

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.

Example ProTookit Application using Visual Studio 2005

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

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.

Open Source Software in Mechanical Computer-Aided Design/Drafting - Part 1 (precursor)

This post is sort of a pre-cursor to what I hope to delve into with this blog i.e. try to identify the state of the art/research of Open Source Software (OSS) in Mechanical Computer-Aided Design (MCAD), Product Data Management (PDM) and Product Lifecycle Management (PLM).

While open source software has had its fair share of success in numerous technology domains e.g. operating system kernels (Linux), operating systems ( Debian, Red Hat), web browsing ( Mozilla Firefox), databases (MySQL), middleware ( JBoss) and others, there is not much we hear about open source in the domain of manufacturing e.g . computer-aided design or product data management. I believe this is primarily due to the following reasons:

1. Firstly the end users of CAD software are not usually programmers. This means that unlike the other popular open source projects the end users of CAD will not contribute code back to the open source software they are using.
2. Secondly programmers rarely delve into the domain of CAD (of course this is when compared to the number of programmers in the other OSS projects)
3. Thirdly (and I believe the most important) most CAD companies such as PTC, Dassault , UGS and Autodesk rarely foster an open attitude or community for their products. These companies build strictly proprietary software providing little in terms of interoperability between each other. Sound familiar? Companies such as Microsoft have been accused of this kind of behavior for decades. But CAD companies, while not as big as Microsoft, will not have such accusations hurled at them and one reason is that there is no clear Monopolist.

So where does this leave open source projects? Well that is what I intend to find out - what kind of support can open source projects give to the users when dealing with MCAD?

Well it turns out from scouring the web that the idea of using open source software for CAD design is quite common but most leads do not end well. While open source software has some great advantages over its proprietary counterparts in other domains, when it comes to CAD, proprietary software has little competition from open source counterparts.

With the next few posts I will try and identify some successful open source CAD projects in addition to some of the not so successful. You may also find some free MCAD software mentioned here even though they are not truly open source. I do not intend this to be a comprehensive list as I but one individual. If I have missed an important open source CAD project do let me know and I will review and include it.

I invite any comments you may have as it would help improve the quality of future posts.