8 Replies Latest reply on Jan 26, 2016 7:24 AM by Checkcheck Master

    VBA vs VB.NET Performance

    Checkcheck Master

      Hi there,

       

      I put my First steps into VB.NET ‘comming from VBA’.

      In my macro one of the modules iterates trough all the dimension names in a part or assembly and search for a particular name and further on an combination of them to create a Configuration Specific Custom Property ‘Size’.

      Surprisingly in VB.NET it takes much longer, approx. 2.5 seconds in total, to iterate trough the dimension names as in VBA, approx a couple of milliseconds/’just a blink’.

      I simply copy and paste the VBA code into VB.NET and make the necessary changes to get it work so the used technique is the same.

      In VBA I use late binding to avoid possible errors regarding the VBA editor(the reason why I switch to VB.NET), I also tried Early binding but regarding performance I found no noticeable difference between them.

      In VB.NET I use early binding which is, I found on the internet, preferred in relation to performance etc.

      I already turned on and off the ‘debug.print’ lines to see the changes with or without.

      For me now it looks like ‘VBA is winning the race’ regarding this subject compared to VB.NET while I thought VB.NET’s performance would be better.

      Since I prefer to run this module for every Part or Assembly to end up with an accurate Size value it is preferred to do this step as fast as possible, 2.5 seconds can be annoying every time a file is saved. 

       

      How should I look to this ?

      Am I doing something wrong or… ?

       

      Greetings!

        • Re: VBA vs VB.NET Performance
          Artem Taturevych

          Hi,

           

          While you are comparing VBA vs VB.NET Stand-alone with equivalent code VBA may perform better by two reasons (it is not required to connect to COM through the interops and it is not fully out-of-the process application).

           

          If you move your VB.NET code to the in-process add-in application - you will see significant performance improvements. You can also use this method to improve your out-of-process performance:

          2014 SOLIDWORKS API Help - CommandInProgress Property (ISldWorks)

           

          Please note that object oriented languages like C#/VB.NET/C++ will only give advantage over the module oriented languages like VB6 in case the OOP approach is used. So if macro is simply translated from VBA to VB.NET there is no much benefit to expect.

           

          Thanks,
          Artem

            • Re: VBA vs VB.NET Performance
              Checkcheck Master

              Thanks Artem for your reaction,

               

              I need to study your answer a bit in detail especially 'CommandInProgress Property (ISldWorks)'  but for now:

              I've already tried to create an add with succes but found that the debugging method takes a lot of time because every time SolidWorks needs to restart to check the add in if the code is working as what you've expect.

              I know there must be a quicker method for debugging in VB.NET but I don't know how, is it easy to explain ?

               

              To be sure: A VB.NET project started as WindowsForm with code behind a button which is connecting to SolidWorks is what you called 'stand alone' ?

              Are there somewhere examples available regarding 'CommandInProgess Property' where I can see how to use that option, so far I don't see them in the help section ?

               

              Greetings!

                • Re: VBA vs VB.NET Performance
                  Artem Taturevych
                  I know there must be a quicker method for debugging in VB.NET but I don't know how, is it easy to explain ?

                  I'm afraid there are no easy ways for this. .NET loads dlls into the SolidWorks domain and you cannot unload them. You can do this only through add-ins interface in .NET but this is quite tricky task. What I'm normally doing is debugging the code through the stand-alone access and deliver as add-in.

                   

                  To

                  be sure: A VB.NET project started as WindowsForm with code behind a

                  button which is connecting to SolidWorks is what you called 'stand

                  alone' ?

                  Exactly right. And the SolidWorks instance is retrieved through something like GetObject or Activator.CreateInstance

                   

                  Are

                  there somewhere examples available regarding 'CommandInProgess

                  Property' where I can see how to use that option, so far I don't see

                  them in the help section ?

                  You just need to set this property to 'true' before your main functions for traversing the dimensions and set back to 'false' after it is finished.

                   

                  Thanks,

                  Artem

                    • Re: VBA vs VB.NET Performance
                      Checkcheck Master

                      Thanks Artem for your answers !

                       

                      So, if I understand you correctly, you write and debug your code in 'stand alone mode' and when it fits your needs you put the code in the Add-in for further debugging ?

                       

                      What you've think, is having multiple modules an issue in VB.NET, somewhere I've read that it's 'old school VBA' and you better use Classes.

                      I'm not experienced enough to answer, in VBA I think modules are a great way to create separate working 'code blocks' and give an overview of the complete project.

                      I'm not that familiar with Classes and be afraid the overview of the complete project will be more difficult.

                      How should I look to this ?

                       

                      Greetings!

                        • Re: VBA vs VB.NET Performance
                          Artem Taturevych

                          Hi,

                           

                          Here are my thoughts:

                           

                          What you've think, is having multiple modules an issue in VB.NET, somewhere I've read that it's 'old school VBA' and you better use Classes.

                          You need to answer the question 'why I'm converting my VBA macro to VB.NET"

                           

                          • If the answer is something like

                          I was told/found information that VBA is obsolete and I have to switch to the 'modern' VB.NET

                          If this is the only reason in my opinion there is no point to switch to VB.NET in this case. To say that the VBA is obsolete and shouldn't be used is the same is to say 'bicycle is obsolete and car needs to be used instead'. VBA and VB.NET are used to solve different tasks in different ways. Microsoft is using VBA in their office applications and considering millions of users and legacy macros I believe the VBA will be alive for a very long time. So if you are comfortable with your VBA macro and have no problems with this, why to change it? VBA is quite powerful to resolve about 90% of automation tasks and 30% of more complex tasks (just my thoughts based on the experience).

                           

                          • If the answer is

                          I have my macro but I need to work with XML, web-services, databases, serialization, advanced graphics etc and it is too hard in the VBA/VB6.

                          In this case .NET is your choice. The .NET Framework provides an extensive set of libraries and help examples to deal with the above tasks

                           

                          • If the answer is

                          I have a macro but I want to grow it into a bigger project and the maintenance and the error handling in VBA is very problematic.

                          Similar to above .NET is your choice. But I would recommend firstly to read about OOP in general to understand the main concepts, then take a look at the proper project architecture (read about design patterns) and only after that learn the syntax of VB.NET/C# or whatever.

                           

                          I'm not experienced enough to answer, in VBA I think modules are a great way to create separate working 'code blocks' and give an overview of the complete project.

                          You could use VB.NET in the same manner as VBA (using modules or classes). Please note that module in VB.NET is actually a class (static class in C#). But as I said before this won't give you any benefits if you just copy-paste your code form macro to VB.NET module. If you copy that to a class it will be the same as module.

                           

                          Try to document clarify the following points:

                           

                          • Will my project grow the functionality over the time?
                          • Will I need to add more integration with other systems like Excel, Databses, PDM, ERP etc.?
                          • Will I ever develop similar project to another CAD platfrom?
                          • Will I extend my development team?

                           

                          If the answers are 'Yes', then read about the design patterns  Software design pattern - Wikipedia, the free encyclopedia which will help to choice the right project architecture to make the maintenance and development as easy as possible. Otherwise think do you really need to convert your macro which you are comfortable with and understand all the logic behind it and how to debug and troubleshot it to VB.NET.

                           

                          Thanks,

                          Artem

                            • Re: VBA vs VB.NET Performance
                              Checkcheck Master

                              Thanks Artem for your detailed answer,

                               

                              The main reason to switch to VB.NET are the problems arising in VBA regarding the 'A serious error occurred' issue where after Solidworks is hanging.

                              Check: A serious error occurred during macro playback.

                              And from another post:

                              •  

                                This known error exist for years now, look for yourself searching the forum for 'A serious error occurred on open macro file. The system could be in an unstable state now.'Find in the search results also my earlier post regarding this problem. In answer from Solidworks to my VAR begin December 2015 they told me it's a bug in the VBA editor:The error is more due to some bug in VBA macro editor and not any programming error or SW API error.This is a known bug and only workaround is to open the corrupted macro in different version than it opened last time, remove references and save it . Now open the saved macro in any version and it should open. You will need to add references before you can compile the macro." For me now it happens many times a day when 'Solid Working' (SW2015 SP5.0), pretty annoying while my complete project structures are based on a few VBA macro's for years now.Sometimes, in the past while coding, I faced that problem and was able to avoid it by changing my code, at least I thought I was.I had the idea the crashes increases after my SW2015 SP2.0 update. A few months earlier, September 2015, Solidwork API support let me know:This error happens as sometimes the references are corrupted in the macro, the usual way to remedy this situation is to open the macro in a backward version of SolidWorks and re-compile the macro by unchecking a reference, re-checking it and saving it. (Using the Tools->References dialog in the VBA IDE). Then opening it in the proper SolidWorks version. Currently only with this way we can avoid this situation. The best way to avoid this is to use late binding while writing the macro i.e. declating variables with Object data type, e.g. Dim swMode as Object.With this approach you don't need to add references to .tlb for your macro (Tools>>References). This will also make sure that all subsequent copies of the macro work fine without getting corrupted. I hope you find this information useful. If you haven't got access to a different version of SOLIDWORKS let me know and I will recover the macro for you. I've tried changing the code regarding late binding and declaring variables as Object to avoid using the references but still I'm not successful running the macro without having the references.Any help regarding declaring as Object would be more than welcome.Is it possible to declare (almost) everything as Object ? Finally I don't know what to think about it, in the last reaction Solidworks stated: '...and not any programming error or SW API error' while on the other hand Solidworks API Support advise how to code one an other...When Solidworks is right it´s not a ´Solidworks problem´ but a 'VBA-editor problem', I've got not the idea someone is busy to solve this problem.I'l hope someone from Solidworks is picking up this conversation and shine a light on it...WTF is going on and how long will it take ?The problem would be still present in SW2016, not a pleasant prospect... I've take the plan to study VB.NET to rewrite some macros or part of macro's to avoid this annoying behavior.If someone has a simple VB.NET example to connect to Solidworks and run a Userform please share.For now I like to simply start a VB.NET macro instead of creating an add-in.I've looked to the add-in template but cannot get in complete control with the code so I like to start with something very simple and basic.Thanks in advance.

                                 

                              So that's why, besides that it's nice programming in VS2015 creating an add in or stand alone things.

                              Also, I'm not a professional programmer and there is always a lot to learn, when I review my code from the past a lot of things can be better.

                              So the question could be, improve the old VBA code or set up something new in VB.NET, something like that.

                               

                              BTW, I've tried my 'GetSize Sub' in an add and indeed the speed is great.

                              Just another consideration to switch, better performance.

                               

                              Is it correct that creating buttons etc. for an add in, for example the SWAddin Template, is al coding ?

                              Are there beside the template other examples how to create different type of buttons and so on ?

                               

                              Greetings!

                                • Re: VBA vs VB.NET Performance
                                  Artem Taturevych

                                  Ok, thank you for the clarification. Regarding the buttons I haven't seen any visual editors so you may write it all from the code behind. Please note there is a lot of places where you can put your UI

                                   

                                  • Command manager/command bar/menu (buttons only)
                                  • Property page. You can use the standard controls as well as windows forms controls wrapped into the ActiveX control
                                  • Task Pane/Model View/Feature Manager Tab - you can add custom ActiveX control which may be a simple User Control created in Windows forms

                                   

                                  Thanks,
                                  Artem