VB or C#

Coordinator
Jun 16, 2010 at 2: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 4:52 PM

C# please.

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

 

Coordinator
Jun 16, 2010 at 4:55 PM
Edited Jun 17, 2010 at 3: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?

******Edit*******

It is nowin C#

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

Sure, add me in.

Is there a list of features requiring backward transaltion ?

 

Coordinator
Jun 17, 2010 at 3: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 

44

SolidWorks 96

243

SolidWorks 97 

483

SolidWorks 97Plus

629

SolidWorks 98

822

SolidWorks 98Plus 

1008

SolidWorks 99 

1137

SolidWorks 2000 

1500

SolidWorks 2001

1750

SolidWorks 2001Plus

1950

SolidWorks 2003

2200

SolidWorks 2004

2500

SolidWorks 2005

2800

SolidWorks 2006

3100

SolidWorks 2007

3400

 SolidWorks 2008  3800
 SolidWorks 2009  4100
 SolidWorks 2010  4400
Jun 17, 2010 at 4: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...

 

Coordinator
Jun 17, 2010 at 4: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 4:43 PM
Edited Jun 17, 2010 at 4: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.

Coordinator
Jun 17, 2010 at 5:09 PM

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