今回は、AutoCAD のカスタマイズの基礎ともいえる コマンド と システム変数 についてご紹介しましょう。どちらも、AutoCAD のカスタマイズでは非常に重要です。特に、AutoCAD API を用いてカスタム コマンドを作成する場合には、コマンドの特性をよく理解することで、カスタム コマンドの振る舞いや定義時の指定を理解し易くなります。
コマンド
AutoCAD のコマンドは、作図や印刷、3D モデリングなどのさまざまな処理の最小単位です。目的に合わせたコマンドを順次実行することで、図面を完成させることができます。AutoCAD の標準コマンドでは、線分や円の作図で使用する LINE[線分] コマンドや CIRCLE[円] コマンド、図形の移動や複写で使用する MOVE[移動] コマンドや COPY[複写] コマンドなど多種多様なものが最初から用意されています。そして、これらのコマンドを組み合わせて 1 つのカスタム コマンドを作成することもできます。AutoCAD API と利用したカスタマイズでは、独自の処理内容を実装するカスタム コマンドを作成することを目的とするのが一般的です。
現在の AutoCAD では、リボン や ツールバーにコマンドを割り当てて、ボタンをクリックすることでコマンドを実行します。もちろん、DOS 版からの AutoCAD の特性も継承しているので、コマンド ライン ウィンドウから直接コマンドを入力して実行することもできます。
実行コンテキスト
さて、コマンドの実行に必要な 実行コンテキスト という要素をご存じでしょうか?AutoCAD API、特に、ObjectARX や AutoCAD .NET API を作成する際には、実行コンテキストを正しく理解しておく必要があります。
実行コンテキストは、簡単に言うと「コマンドを動作させる内部的な環境」のことです。多くの場合、コマンドを実行するために、AutoCAD の画面上に図面が表示されていることが前提になります。言い換えれば、コマンドの実行は、ドキュメント(図面を表示する MDI 子ウィンドウ) に依存します。
通常、AutoCAD のコマンドを実行は、コマンドは現在アクティブなドキュメントに表示されている図面に作用します。このようなコマンドは、ドキュメント実行コンテキスト で動作するコマンドと考えてください。ドキュメント実行コンテキストで動作するコマンドは、コマンドの実行前と実行後で、対象とするドキュメントが同一である点に注意してください。AutoCAD の標準コマンドや、API を使って作成するカスタム コマンドのほとんどは、このドキュメント実行コンテキストで動作します。ドキュメント実行コンテキスト コマンドは、コマンド実行中にアクティブなドキュメントを切り替えても、ドキュメント毎に独立して実行状態を維持できる特徴があります。例えば、Drawing1.dwg を表示したドキュメントに LINE コマンドを使って線分を作図している途中でも、Drawing2,dwg を表示するドキュメントをアクティブにして、別のコマンドを入力できます。その後、Drawing1,dwg に表示を切り替えると、入力途中だった LINE コマンドを継続することができます。
一方、コマンド実行前と後のドキュメントが異なるようなコマンドも存在します。新規図面を作成する NEW [新規作成] コマンドや OPEN [開く] コマンドが、その代表例です。このようなコマンドを アプリケーション実行コンテキスト で動作するコマンドといいます。
カスタムコマンドを作成する場合には、コマンド フラグと呼ばれる値をコマンド定義に加えることで、定義するコマンドをドキュメント実行コンテキストで実行させるか、アプリケーション実行コンテキストで実行させるかを指定できます。具体的には、ObjectARX でアプリケーション実行コンテキスト コマンドを定義する場合にはコマンド フラグに ACRX_CMD_SESSION を、AutoCAD .NET API で同様の定義をする場合には Session をそれぞれ指定するしなければなりません。これらを特に指定しなければ、コマンドはドキュメント実行コンテキストで実行されます。
このような状況でカスタム コマンドの問題が発生しがちです。ドキュメント実行コンテキストで定義したカスタム コマンド内で OPEN コマンドを呼び出すことを考えてみましょう。そのカスタム コマンドを実行すると、コマンドの実行途中で実行コンテキストが開いたドキュメントに移動することになります。つまり、対象となるドキュメントが変わってしまします。AutoCAD は、ドキュメント実行コンテスト コマンドが、途中で対象ドキュメントを変更する処理を許容しないため、ドキュメント実行コンテキストで定義したカスタム コマンドの中で OPEN コマンドを呼び出すと、その処理は中断してしまいます。このような場面では、このカスタム コマンドはアプリケーション実行コンテキストで定義されるべきです。
図面を1つ1つ AutoCAD に開きながら自動製図や印刷を繰り返すコマンドを作成する場合には、明示的にアプリケーション実行コンテキストで実行されるような指定をしないと、処理途中でコマンドの実行が中断していまいますので注意してください。
もう1点、アプリケーション実行コンテキストで定義したコマンド内で図面データベースにアクセスするような場合は、必ず対象となるドキュメントを特定する意味で、ドキュメント ロック の処理を挿入するようにしてください。アプリケーション実行コンテキストで動作するコマンドは、そのままだとドキュメントに依存しないため、明示的に作業対象のドキュメント、すなわち、ドキュメントに表示されている図面データベースを明示的に指定しなければなりません。ちょうど、http://tech.autodesk.jp/faq/faq/adsk_result_dd.asp?QA_ID=7789 のように、モードレス ダイアログからドキュメントにアクセスするようなケースと同じ理由です。
コマンド グループ
ネイティブ コマンドとは、AutoCAD の標準コマンドと同等の働きをするコマンドを指します。ここで言う同等とは、コマンド名の前に ' を付加して割り込みコマンドとして動作することが可能で、AutoLISP の (command) 関数 や ObjectARX の acedCommand() 関数からの呼び出しが可能であることを意味します。ObjectARX や AutoCAD .NET API アプリケーションでは、主にこの方法でコマンドを登録を行ないます。一方、AutoCAD には、このネイティブコマンドとは別に AutoLISP の (defun) 関数や ObjectARX の acedDefun() 関数で定義する AutoLISP コマンドが存在しています。特に理由がない限り、現在では AutoLISP コマンドを利用することは稀なので、ここでは、AutoLISP コマンドについての説明は省略しておきます。
1 つの ObectARX ファイルや .NET API ファイルで複数のコマンドを定義することができますが、各コマンドは、他のアプリケーション ファイルが定義するコマンドと重複を避ける必要があります。さもないと、せっかく実装したコマンドで、他社が定義したアプリケーションの同一コマンドが実行されています可能性があります。ネイティブ コマンドの登録時には、コマンド グループも登録できるので、企業単位やモジュール単位で一意となるコマンド グループを登録するようにしてください。コマンド グループを利用することで、同じコマンド名でコマンドが重複登録されてしまった場合でも、コマンドの呼び出し方法で、問題を回避する手法を提供します。
AutoCAD は、ObjectARX や .NET API の各種カスタム アプリケーションが定義するコマンドを、カスタム アプリケーションがロードされた順番にスタック管理しています。ユーザがコマンドを実行のためにコマンド名を入力したり、ボタンをクリックしてコマンド名が呼び出されると、AutoCAD は、スタックの上部からコマンドを見つけにいきます。そして、そのコマンド名を見つかった段階でそのコマンドを実行をします。
この仕組みでは、同じコマンド名を定義するアプリケーションが複数ロードされている場合、最後にロードされたアプリケーションのコマンドが実行されることになります。ここでは、先にロードされているアプリケーションのコマンドを呼び出すために、ピリオドを挟んでコマンド グループ名とコマンド名を一緒に呼び出すことでができます。次の例では、GRP1 コマンド グループ名と GRP2 コマンド グループ名を使って、それぞれの TEST コマンドを呼び出した場合のコマンド ライン ウィンドウでの表示です。
このように、カスタマイズを前提としてコマンドを見ると、意味深な要素が含まれることが理解いただける思います。
システム変数
システム変数は、AutoCAD が持つ様々なコマンドが内部的に使用する値です。システム変数を知ることで、AutoCAD をどこまで設計者の望むものにカスタマイズできるのか、その目安を把握できます。システム変数には、読み取り専用のものもありますが、多くは SETVAR[変数設定] コマンドを使って値を上書き設定することができます。また、API からもシステム変数の値を設定したり取得したりする機能を提供しています。これによって、カスタム コマンドの中からシステム変数の値を変更してしまうことできます。
少しシステム変数の例を見ておきましょう。たとえば、UNITS[単位管理]コマンドで設定する内容は、システム変数 LUNITS、LUPREC、AUNITS、AUPREC、ANGDIR、INSUNITS、LIGHTINGUNITS の各値に反映されます。
また、コマンド操作では直接用意されていない機能も、システム変数を設定することで実現できる場合があります。たとえば、” 2D ワイヤフレーム” 表示スタイルの状態でシステム変数 DISPSILH と ISOLINES の値を変更すると、同じ視点でも、3D ソリッドの球を外形線だけを表示させることができるようになります。
そのほか、システム変数 SDI を 1 に設定すると、AutoCAD R14 までの AutoCAD と同じように、1つの図面しか開けないような環境(シングル ドキュメント インタフェース:SDI) に変更することもできます。この機能は、API を利用したプログラム資産の動作互換のためのものですが、複数の図面を開くことができなくなるので、現在の AutoCAD ユーザには好まれません。
このように、システム変数の変更で、AutoCAD の振る舞いをコントロールすることができるようになります。 特に、API によるカスタマイズを考えられているユーザは、一度、どのようなシステム変数があるか チェックすることをお勧めします。
前述のとおり、システム変数はカスタム コマンドの中で呼び出すこともできるので、カスタム コマンド実行時に、必要に応じて作図環境を変えていくこともできるのです。
コマンドとシステム変数は、AutoCAD のバージョンアップに沿って新しく登場したり、場合によっては削除されたものがあります。カスタム アプリケーションをお持ちの方は、AutoCAD のバージョン アップに沿った移植作業で、この情報が重要になる場合があるはずです。最後に、AutoCAD R14 時代からのコマンドとシステム変数の履歴をご提供しておきましょう。この一覧は、昨年オートデスクを退社された高村さんから引き継いだものに AutoCAD 2014 の情報を付け加えたものです。高村さん、ありがとうございました !!
AutoCAD R14~2014 コマンド履歴: コマンド履歴をダウンロード
AutoCAD R14~2014 システム変数履歴: システム変数履歴をダウンロード
By Toshiaki Isezaki
、
コメント