これまで、必要に迫られて、あるいは興味本位で、Inventorのカスタマイズプログラムを作ってきました。VBAのマクロで作ったものを、より実装のしやすいiLogicルールで作成したり、移植したり。

iLogic はとても良いけど、凝ったものを作ろうとすると大変。デバッグがやりにくかったり、iLogic API だけではうまく作れなかったり。

最近では、作ったiLogcルールの数が多くなりすぎて、管理が大変になってきました。そこで、Visual Stuidoを使って iLogicのルールの部分をクラス化して、一つのVBプロジェクトでDLLを作成するようにしました。DLL内のクラスを使ったiLogicルールに変えるということです。

DLL化のメリット

色々ありますが、自分としては、順に

1. 開発用プロジェクトの一元化

2. デバッグが容易

3. iLogicルールを短くできる

開発用プロジェクトの一元化

ひとつのVBプロジェクトにプログラムをまとめられるのが一番便利です。別々にルールを作っていると、ルール間で、表現や書式に食い違いがおきがちです。修正するのも結構面倒。それが、同じプロジェクト内にコードがあるので、修正がとても楽になりました。

もちろん、コードの流用とか共有とかもできるので、プログラム作成の効率自体も格段に良くなりました。

iLogic エディタ側でルールを書くときは、一つのDLLから、ルールで使用するクラスを選択すればよいです。

デバッグが容易

VBAやVBのIDEに慣れた身には、iLogic のルールエディタを使うのは苦痛です。ブレイクポイントの設定や変数のウォッチができないのは相当つらいです。
これが、Visual Stuidoからデバッグをすることで、Visual Studio のデバッグ環境が使えるようになります。

iLogicルールを短くできる

これまで、iLogicルールとして記述していたロジックのほとんどがDLL側で記述するようになったので、iLogicルールの方は大変に簡潔になりました。これだと、後でルールを開いたときも内容を直感的に理解することができます。

今後の課題

今後の課題は、iLogic API と Inventor API の使い分けです。
iLogic API は、Inventor API を使うと結構長くて面倒くさい処理を簡単に実現できますが、反面、融通が利かないと気があります。

使い方を深く想定しておかないと、肝心な場面で使えないルールになる危険があります。プログラム作成の方針を立てるときに結構気にします。

最新のDLL

このブログで紹介した iLogic ルール用の最新のDLLは、こちらから