Category: SOLIDWORKS

💡 Complete Code Example Available on GitHub:https://github.com/BlueByteSystemsInc/SW_API_Tips_Tricks/tree/master/ReportProgress When working with the SOLIDWORKS API, it’s common to encounter operations that take significant time—such as traversing large assemblies, analyzing complex parts, or batch processing files. Unlike some applications that allow multithreading for responsiveness, SOLIDWORKS operates primarily on a single-threaded model. This means traditional threading approaches aren’t ideal for providing user feedback on lengthy operations. However, reporting progress for long operations is still possible through SOLODWORKS’ built-in API features, which allow developers to display progress and offer cancellation options, ensuring your application remains responsive. Why Not Use Threads? While you might instinctively think about using separate threads to keep your user interface responsive, SOLIDWORKS is inherently single-threaded. Interacting with the SOLIDWORKS API from multiple threads can lead to instability and unpredictable behavior, including crashes. Hence, relying on SOLIDWORKS’ native progress reporting tools is strongly recommended. SOLIDWORKS’ Built-in Progress Reporting: UserProgressBar SOLIDWORKS provides a straightforward mechanism for reporting progress to users via the UserProgressBar interface. This built-in progress bar not only shows progress visually but also allows users to cancel ongoing tasks. The user can cancel an operation by pressing the Escape key. Here’s how you can implement it effectively in your SOLIDWORKS API programs. Example Implementation in C# Let’s illustrate with a practical example. The following snippet demonstrates a typical scenario: performing repetitive, time-consuming operations (like face analysis) and reporting progress clearly to users: Key Points in the Example: Benefits of Using SOLIDWORKS’ Progress Bar:

Writing SOLIDWORKS macros and add-ins is a wonderful thing to do in order to save repetitive work. But nothing spoils the experience more quickly than sluggish performance. A performance-intensive macro can negate any productivity gain and drive users bughouse. So, how do we make our SOLIDWORKS API macros and add-ins soar? This is where understanding useful API calls to optimize SOLIDWORKS performance becomes essential, helping you write faster and more efficient automation. The answer is in some special API calls and best practices that keep SOLIDWORKS from wasting time doing unnecessary work behind our backs. Let’s dive into the most precious SOLIDWORKS API optimization techniques and take your code flying! How to Speed Up and Optimize the SOLIDWORKS API When your attempts at optimizing SOLIDWORKS performance stop in their tracks, it is usually because your code is causing SOLIDWORKS to do things that are not necessarily required in order for the task to be executed. UI updates, feature tree updates, and screen redraws take even the most mundane macro forever to do. The below API calls are your weapon to combat this issue. 1. What is CommandInProgress? Think of CommandInProgress as telling SOLIDWORKS, “Hey, I’m busy doing something important, so don’t bother with UI updates or other background processes until I’m done.” Setting this property to True is one of the most effective ways to significantly improve macro execution speed, especially when performing complex tasks. Use it: Remember to set CommandInProgress to False once your operation is done. If you don’t, part of the SOLIDWORKS UI will be unusable, and you’ll need to manually restart SOLIDWORKS in order to fix it. 2. DoEvents This is an old VBA and VB.NET call that releases control to the operating system so it can respond to other events while your macro is executing. It’s great for making the UI responsive during lengthy operations so the user has a chance to click a cancel button or observe an updating progress bar. Use it with caution, though! Multiple calls to DoEvents will really slow down your macro. For optimum performance, in the majority of situations, don’t call DoEvents at all. Example: 3. AddToDB Manual creation of new sketch entities, SOLIDWORKS will usually try to snap them to nearby geometry or grid points to assist the user. Useful for manual sketching, but wasteful when creating programmatically. AddToDB allows you to avoid this snapping process and add entities directly into the database, which can result in a performance gain. Example: 4. DisplayWhenAdded Similar to AddToDB, this API call is a great way to speed up the generation of sketches. If you call DisplayWhenAdded with False, you prevent SOLIDWORKS from adding new sketch entities to the screen until you’ve specifically requested it to. This is a real time-saver when macros are creating a lot of sketch entities. Example: 5. EnableFeatureTree The FeatureManager Design Tree of SOLIDWORKS is a wonderful piece of work, but constant updating during the middle of a macro is a performance and efficiency killer. You can avoid the tree from being updated until you are done with your activities by using EnableFeatureTree = False. Example: 6. EnableConfigurationTree If the macro is manipulating configurations, you might be able to gain some speed by disabling the config tree updates using EnableConfigurationTree. Example: 7. EnableGraphicsUpdate This is a mandatory use for any macro that performs geometry-intensive actions. Setting EnableGraphicsUpdate to False stops the SOLIDWORKS graphics window from updating while your code makes its changes, resulting in an incredible performance gain. Make sure to set it back to True afterward, however, so the user can see the results! Example: 8. UserControlBackground To obtain the optimum speed boost, you can hide the full SOLIDWORKS application window through UserControlBackground. This is useful when you have a stand-alone application that is doing a very complex, non-visual task. Example: 9. Lock/Unlock Model The Lock API call will exclude the user from seeing the UI while your macro is running. This can be useful to get the user out of your hair so that user activity won’t interrupt your code. Be aware, however, that certain API calls, like InsertNote, will not function if the model is locked. Example: 10. Do not use Excel Interop dll If you’re writing a .NET add-in or desktop application and you’re reading from or writing to Excel, it is recommended that you use the services of a library called EPPlus instead of the Excel interop DLL. You will notice a far better performance outcome when you make the switch. By using these API calls wisely, the performance of SOLIDWORKS macros and add-ins can be significantly optimized. The conclusions in summary are: