SolidWorks APIの深淵：ConfigurationManagerを支配するメモリ管理とバッチ処理の最適解
SolidWorks APIを扱う多くのエンジニアが陥る罠がある。それは「コンフィギュレーションを切り替えれば、全てがリセットされる」という甘い幻想だ。
`ConfigurationManager`を通じてコンフィギュレーションを切り替える際、裏側では膨大なメモリの再構築とジオメトリの再計算が走っている。これを安易なループで回せば、数千行のコードはメモリリークの温床となり、やがてSolidWorksは沈黙する。
本稿では、レガシーな環境においても安定して動作する、「オブジェクトのライフサイクルを制御したバッチ処理」の極意を伝授する。
—
1. オブジェクト再利用の鉄則とメモリ解放の真実
VBA環境において、オブジェクトの参照を保持し続けることは死を意味する。特に`ModelDoc2`や`Configuration`オブジェクトをループ内で宣言し、不用意にスタックを汚染してはならない。
「明示的な解放」は、単なる作法ではなく、SolidWorksのCOMポインタを解放するための必須儀式だ。
‘ 悪い例：ループ内で頻繁に生成・破棄が曖昧になる
‘ 良い例：メインのドキュメントポインタを維持しつつ、必要なコンフィグのみを解決する
Public Sub BatchProcessConfigurations(swApp As SldWorks.SldWorks)
Dim swModel As SldWorks.ModelDoc2
Dim swConfMgr As SldWorks.ConfigurationManager
Dim swConf As SldWorks.Configuration
Dim vConfNames As Variant
Dim i As Long
Set swModel = swApp.ActiveDoc
If swModel Is Nothing Then Exit Sub
Set swConfMgr = swModel.ConfigurationManager
vConfNames = swModel.GetConfigurationNames
For i = LBound(vConfNames) To UBound(vConfNames)
‘ コンフィギュレーションの切り替え
‘ swModel.ShowConfiguration2 が失敗した場合のハンドリングが肝
If swModel.ShowConfiguration2(vConfNames(i)) Then
‘ 処理を実行する前に再構築を強制
swModel.ForceRebuild3 False
‘ メモリ負荷の高い処理はここで実行
ProcessCurrentState swModel
End If
‘ ドキュメントのクリーンアップは不要だが、
‘ 大量ループ時はDoEventsでメッセージキューをクリアする
DoEvents
Next i
‘ 明示的な解放（伝説的アーキテクトの礼儀）
Set swConf = Nothing
Set swConfMgr = Nothing
Set swModel = Nothing
End Sub
—
2. コンフィギュレーション制御のボトルネックを排除する
`ShowConfiguration2`メソッドは、UIの更新をトリガーにすることがある。バッチ処理中に画面の描画を更新させるのは、パフォーマンスを劇的に低下させる最大の要因だ。
パフォーマンス最適化の極致
- Freeze Modeの活用: 大規模アセンブリの場合、処理前に`swModel.FreezeAllFeatures True`を検討せよ。
- UI更新の停止: `swApp.Frame.KeepAlive = False` は利用できないが、`swApp.Visible = False`（バックグラウンド実行）または`swModel.Visible = False`に近い挙動を制御することで、描画負荷を排除する。
—
3. レガシー環境におけるWindows API連携の重要性
大規模な構成部品バッチ処理を行う際、SolidWorksのプロセスが一時的なメモリ肥大で不安定になることがある。そんな時、VBAからWindows APIを呼び出し、メモリ使用量を監視し、必要に応じて`EmptyWorkingSet`を叩くのがシニアの流儀だ。
If VBA7 Then
Private Declare PtrSafe Function EmptyWorkingSet Lib “psapi.dll” (ByVal hProcess As LongPtr) As Long
Private Declare PtrSafe Function GetCurrentProcess Lib “kernel32” () As LongPtr
Else
Private Declare Function EmptyWorkingSet Lib “psapi.dll” (ByVal hProcess As Long) As Long
Private Declare Function GetCurrentProcess Lib “kernel32” () As Long
End If
‘ 処理の合間にメモリを強制解放するユーティリティ
Public Sub FlushMemory()
EmptyWorkingSet GetCurrentProcess()
End Sub
※この関数は多用してはならない。Windowsが最適化しようとしているメモリを強制的にスワップアウトさせるため、多用はむしろ処理速度の低下を招く。あくまで「大きな切り替えの合間」に使う外科手術的なアプローチだ。
—
4. チーフアーキテクトからの助言
「自動化」とは、単にマウス操作を置き換えることではない。「SolidWorksの内部エンジンがどう動くかを理解し、その挙動に同調すること」である。
1. エラーハンドリングの徹底: コンフィグの切り替えに失敗した際、例外をキャッチせずに処理を続行すると、後の整合性が崩壊する。必ず`If`文で戻り値を検証せよ。
2. モデルの整合性: 構成部品が「解決済み」か「軽量」かを常に意識せよ。バッチ処理の際は、原則として全てのコンフィギュレーションを解決済みモードで処理することが安全の定石である。
SolidWorks VBAは、決してレガシーな遺物ではない。APIの深淵を覗き込み、メモリの挙動を支配できる者にとっては、現在もなお最強の自動化ツールであり続けている。
諸君のコードが、SolidWorksの巨大なジオメトリエンジンを意のままに操ることを期待する。
