SolidWorks VBAを極限まで加速させる：描画抑制とメモリ管理の深淵
多くのエンジニアが「SolidWorksのマクロは遅い」と嘆く。だが、それはSolidWorksのせいではない。CPUのサイクルを、本来不要な「描画の再計算」という無駄なゴミ捨てに浪費させているコードを書いている、設計者の責任だ。
数千ものフィーチャを生成・編集する際、画面の更新を都度行えば、当然ながらパフォーマンスは崩壊する。今回は、数分かかっていた処理を数秒で終わらせる、現場の極致とも言える最適化テクニックを伝授する。
—
1. 描画抑制の真髄：`EnableGraphicsUpdate`の正しい運用
最も初歩的でありながら、最も見落とされているのが `SwApp.Visible` の制御ではない。真の高速化は `ModelDoc2` レベルでの描画抑制にある。
以下のコードは、フィーチャ生成時の「見た目」の更新を完全に遮断し、メモリ上での計算処理のみに専念させるための定石だ。
‘ 【重要】処理の開始と終了で確実にフラグを制御する
Public Sub OptimizeFeatureCreation()
Dim swApp As SldWorks.SldWorks
Dim swModel As SldWorks.ModelDoc2
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
‘ 描画の更新を凍結する
swModel.EnableGraphicsUpdate = False
‘ これにより、フィーチャ生成中の再描画コストをゼロにする
‘ 画面はフリーズしたように見えるが、内部処理速度は劇的に向上する
Call ExecuteHeavyProcess(swModel)
‘ 処理完了後に更新を戻す
swModel.EnableGraphicsUpdate = True
‘ 強制的に画面を再描画して最新状態にする
swModel.GraphicsRedraw2
End Sub
2. FeatureManagerの再計算抑制：`FeatureManagerFreeze`
フィーチャツリーが数千件に及ぶ場合、各フィーチャを追加するたびにモデルの再構築（Rebuild）が走り、依存関係のチェックが行われる。これは大規模アセンブリや複雑なパーツにおいて致命的だ。
ここで使うべきは `FeatureManager` のプロパティ操作である。
‘ フィーチャ操作時の再構築を抑制するテクニック
swModel.FeatureManager.EnableFeatureTree = False ‘ ツリーの更新を停止
‘ … ここで大量のフィーチャ生成処理を実行 …
swModel.FeatureManager.EnableFeatureTree = True
シニアエンジニアへの忠告：
`EnableFeatureTree` を切った状態で異常終了すると、SolidWorksのUIが不安定になることがある。必ず `On Error GoTo` でエラーハンドラを書き、例外発生時にも確実にフラグを `True` に戻す「安全装置」を実装すること。
—
3. オブジェクトのライフサイクルとメモリの解放
VBAはガベージコレクションが甘い。特に `swModel.Extension.SelectByID2` などで大量のオブジェクトを扱う際、明示的に参照を解放しないとメモリリークを起こし、後半になるほどマクロの速度が低下する。
- `Set Object = Nothing` の徹底: ループ内で使用した `Feature` や `Sketch` オブジェクトは、スコープを抜ける前に必ず明示的に解放する。
- `Variant` 型の回避: 型指定のない `Variant` はメモリ効率が悪く、処理速度も遅い。可能な限り `SldWorks.Feature` 等の特定クラスで宣言すること。
Dim swFeat As SldWorks.Feature
‘ ループ処理
For i = 1 To 1000
Set swFeat = swModel.FeatureManager.Insert…
‘ 処理後すぐに解放
Set swFeat = Nothing
Next i
—
4. レガシー環境でのWindows API活用
もしマクロがネットワークドライブ上の重いファイルにアクセスしている場合、SolidWorksの描画抑制だけでは不十分なことがある。Windows APIの `Sleep` を駆使し、IO負荷を調整するのも一つの手だが、真のプロは「再構築キュー」を制御する。
`swModel.ForceRebuild3` を乱用してはならない。これは全ジオメトリを強制的に再計算させる重い命令だ。変更が必要なフィーチャのみを特定し、最小限の再計算に留めるためのフラグ管理を徹底すること。
—
最後に：エンジニアとしての矜持
コードを速くすることは、単なる自己満足ではない。それは、設計者が「待たされる時間」を削減し、彼らが本来向かうべき「創造的な設計」にリソースを集中させるための投資だ。
「とりあえず動く」コードから、「極限まで最適化された」アーキテクチャへ。
SolidWorksのAPIは、あなたの意図をそのまま反映する忠実な道具である。その道具をどう使いこなすかは、設計者であるあなた自身の美意識にかかっている。
もし、これでも速度が改善しない場合は、マクロの手順そのものに設計上の欠陥がある可能性が高い。アルゴリズムを再考せよ。SolidWorksは、正しく命令されれば、期待以上の速度で応えてくれる。
