Top Three Excuses For Not Switching To Visual Basic.NET (From Visual Basic 6.0 or VBA)
Posted by Jeff Cope at 25 November, 2007, 11:45 pmBecause so many SolidWorks API users appear to use either VBA or Visual Basic 6.0 as their primary development environment, I thought a post about upgrading to .NET might be in order. There are endless possibilities for a topic even within that category but I feel that there are so many misconceptions about Visual Basic.NET amongst SolidWorks API users that it makes the most sense to use my little bit of time and real estate here to undo some of those misconceptions. Those who do SolidWorks API development for their actual job should already know these but individuals who perform SolidWorks customization through the API as their “secondary job” or as a hobby might benefit from the post.
Excuse 1 -Visual Basic.NET is expensive unlike VBA, which is free.
Truth - Visual Basic.NET is included in the free Visual Studio 2005 Express offering from Microsoft. It is a scaled down version of the pay version but offers most of the capabilities in the pay version. You will be able to do just about everything you need to do with the SolidWorks API except develop SolidWorks Add-ins. For around $300 US, you can get a hold of Visual Studio 2005 Standard, which has all of the features of the Express version plus a few more, including the ability to create SolidWorks Add-ins.
Excuse 2 – VBA is easier to use than Visual Basic.NET.
Truth – VBA has an advantage for very simple tasks but for more complex tasks, I think Visual Basic.NET has the advantage in the ease of use category. Visual Basic.NET gives you access to the .NET Framework, a series of libraries that provide advanced capabilities for working with Windows, Windows applications, web applications and others. The libraries that make up the .NET Framework are a significant improvement to the COM libraries that are available with VBA or Visual Basic 6.0. Additionally, the development environment itself is improved over the VBA and Visual Basic 6.0 development environments. Probably the biggest enhancement is the background compiliation error checking. With this feature, Visual Basic.NET alerts you to most errors as you type. With the older VBA environment, you found out about most compile errors only when you were brave enough to run the Macro. With Visual Basic 6.0, you found out when you attempted to compile your application.
Excuse 3 – I will have to completely re-write all of my VBA Macros and Visual Basic 6.0 applications in .NET if I want to use them with my .NET applications.
Truth – Visual Basic has a conversion wizard that will convert Visual Basic 6.0 and VBA code to Visual Basic.NET. It is often a good idea to re-write your VBA and/or Visual Basic 6.0 stuff for .NET in order to take advantage of the full power of .NET but it is optional. Re-writing for .NET will also help you to better understand the different way that things are done in .NET but again, this is optional. Additionally, if you have ActiveX controls written in Visual Basic 6.0 (or any language that supports COM) then you can “plug in” those components to your .NET application.
If you enjoyed this post, make sure you subscribe to my RSS feed!
- Bookmark :
- Digg
- del.icio.us
- Stumbleupon
- Redit it
I think the .NET is much better then VB 6. I understand the conversion but who says you cant have both and do all new stuff in .NET
You are correct that you can leave the old stuff in VB6.0 so it isn’t always an either/or proposition. For SolidWorks applications, however, VB6.0 is no longer supported and I have had strange behavior when I attempt to run SolidWorks addins written in VB6.0.
Since this is a SolidWorks-related blog, I decided to focus on conversion but for general applications, there is not necessarily a need to migrate legacy code.
Thanks for your comment.
When did vb6.0 becoome unsupported by SWX?
VB 6.0 became unsupported by SolidWorks beginning with SolidWorks 2006. It will still work in some cases but for addins that have a user interface, you can get very erratic behavior(e.g. controls appearing out in space and generally all over the place).
I specifically recall seeing the issue on a Windows form with controls on multiple tabs. I reported the issue to SolidWorks API Support and they told me that VB6.0 was no longer supported and that I should move to .NET, so I did. I am glad too.
Hi Jeff,
I am rather new to developing SW macros and the Solidworks API, so there is much for me to learn. As a beginner I started with VB 6.5 since that is the default that you get when you start to record a macro (I think).
I have not moved past using VB 6.5 in part because I don’t know how and also because I am able to accomplish the automation tasks that I need. I am willing to give VB.Net a try and have already installed VB 2008 Express.
So how I can go from something like a pre-recorded macro that is VB 6.5 to be implemented in VB.NET? Also, when I want to share the macro with my colleagues, how do I package it and send it out? I have had many issues with the portability of my macros as it is. Would VB.NET be more portable? Would my colleagues need to download VB 2008 Express in order to install VB.NET too? Or would they just need to install the latest .NET framework from microsoft update?
Will,
You should be able to use VSTA in SolidWorks 2009 to record a Macro in .NET syntax. I don’t do as much with Macros anymore so you may want to check with Mike Spens over at GoEngineer since he presented on this at SolidWorks World this year.
Best regards,
Jeff