Comments on: Top Three Excuses For Not Switching To Visual Basic.NET (From Visual Basic 6.0 or VBA) http://extensiblecad.com/words/2007/11/25/top-three-excuses-for-not-switching-to-visual-basicnet-from-visual-basic-60-or-vba/ SolidWorks and PDMWorks Enterprise Development Blog Wed, 25 May 2011 12:31:13 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Jeff Cope http://extensiblecad.com/words/2007/11/25/top-three-excuses-for-not-switching-to-visual-basicnet-from-visual-basic-60-or-vba/comment-page-1/#comment-353 Jeff Cope Mon, 16 Feb 2009 18:27:16 +0000 http://extensiblecad.com/words/?p=51#comment-353 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 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

]]> By: Will http://extensiblecad.com/words/2007/11/25/top-three-excuses-for-not-switching-to-visual-basicnet-from-visual-basic-60-or-vba/comment-page-1/#comment-348 Will Tue, 10 Feb 2009 19:18:23 +0000 http://extensiblecad.com/words/?p=51#comment-348 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? 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?

]]> By: Jeff http://extensiblecad.com/words/2007/11/25/top-three-excuses-for-not-switching-to-visual-basicnet-from-visual-basic-60-or-vba/comment-page-1/#comment-27 Jeff Thu, 29 Nov 2007 18:59:47 +0000 http://extensiblecad.com/words/?p=51#comment-27 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. 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.

]]> By: Neil http://extensiblecad.com/words/2007/11/25/top-three-excuses-for-not-switching-to-visual-basicnet-from-visual-basic-60-or-vba/comment-page-1/#comment-26 Neil Thu, 29 Nov 2007 16:26:30 +0000 http://extensiblecad.com/words/?p=51#comment-26 When did vb6.0 becoome unsupported by SWX? When did vb6.0 becoome unsupported by SWX?

]]> By: Jeff http://extensiblecad.com/words/2007/11/25/top-three-excuses-for-not-switching-to-visual-basicnet-from-visual-basic-60-or-vba/comment-page-1/#comment-25 Jeff Thu, 29 Nov 2007 05:14:17 +0000 http://extensiblecad.com/words/?p=51#comment-25 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. 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.

]]>