VB or C#

Jun 16, 2010 at 3:26 PM

right now i have started the project with VB programing but it will be very simple to change it to C# at the beginning
post that languge is best and lets see what we can do.

Jun 16, 2010 at 5:52 PM

C# please.

Are you creating a stand-alone executable or an addin ?


Jun 16, 2010 at 5:55 PM
Edited Jun 17, 2010 at 4:06 PM

Right now it an Addin
but that not a bad Idea it can be design to do both
C# is what I was think to

Do you want to be part of the Team?


It is nowin C#

Jun 17, 2010 at 4:43 PM
Edited Jun 17, 2010 at 4:44 PM

Sure, add me in.

Is there a list of features requiring backward transaltion ?


Jun 17, 2010 at 4:57 PM

ok you in the Team

there is no list right now I was think of creating an list with the featureTypeName and  Version History Value as below

Major SolidWorks Version

Version History Value

SolidWorks 95 


SolidWorks 96


SolidWorks 97 


SolidWorks 97Plus


SolidWorks 98


SolidWorks 98Plus 


SolidWorks 99 


SolidWorks 2000 


SolidWorks 2001


SolidWorks 2001Plus


SolidWorks 2003


SolidWorks 2004


SolidWorks 2005


SolidWorks 2006


SolidWorks 2007


 SolidWorks 2008  3800
 SolidWorks 2009  4100
 SolidWorks 2010  4400
Jun 17, 2010 at 5:22 PM

What API version will this addin use?  Will users be required to have SW 2010 to run this?  How would a user convert a SW2010 document to SW2001 if they have SW2001?  They won't be able to even open the SW2010 document for conversion...


Jun 17, 2010 at 5:25 PM

This is one of the big thing that need to be figured out to see if this will even work

Can this be made to open an Sw2010 part where the user only has 2008  i'm hope with the 2010 DLL file that it can put I don't know

Jun 17, 2010 at 5:43 PM
Edited Jun 17, 2010 at 5:49 PM

If you look through the API help, for example, ITreeControlItem; the GetParent method is only available from SW2008 SP2.

Legally, I do not know that the Interop assemblies can be redistributed?

Technically, SW2010 Interop assemblies might work with SW2008, less functionality that is not supported by SW2008. 

One option is to create this code late-bound w/o Interop assemblies.


object swApp = GetObject("SldWorks.Application");


and use Microsoft.VisualBasic.CompilerServices.NewLateBinding (LateGet, LateCall) to retrieve objects and call methods.  This could be accomplished with the Dynamic type in .NET 4.0 as well.  But this would get annoying.

Take a look at COM Types in http://solidworks.codeplex.com/wikipage?title=Generic%20Addin%20Framework%20R1&referringTitle=Documentation.  If we have the Interop assemblies then we can get the type from any __ComObject, by querying its interface.  So if you have an object that you retrieved from the SelectionMgr, you'll be able to retrieve the SW Interop types it supports.

I think it makes most sense to code this against SW2010, then upgrade to SW2011, etc.  This will open a possible revenue stream.  Let's say an engineer has SW2005 and he receives a SW2010 model.  Well, he can call www.swtranslationservices.com to have it translated to SW2005 for $50, or he can go back to the customer and ask them to translate it for him.  Why not...  It would actually makes sense to start marketing www.swtranslationservices.com as soon as the prototype is done since the more models you translate the more bugs you fix.

Jun 17, 2010 at 6:09 PM

We Don't want Legal problems -- i will need to look in to that