「Command-s」の版間の差分

提供:GizmoLabs - だいたい CAD LISP なサイト
編集の要約なし
69行目: 69行目:
  (command-s "._line" "0,0" PAUSE "")
  (command-s "._line" "0,0" PAUSE "")


* 注意 : command-s 関数は command 関数と似ているが、AutoLISP 式を入力するときに進行中の CAD コマンドがある場合、U または UNDO を使用してシステムの状態をロール バックするときは注意が必要です。この場合、UNDO を実行すると、進行中のコマンドが失敗したり、CAD が異常終了する可能性がある。
* 注意 : command-s 関数は command 関数と似ているが、AutoLISP 式を入力するときに進行中の CAD コマンドがある場合、U または UNDO を使用してシステムの状態をロール バックするときは注意が必要。この場合、UNDO を実行すると、進行中のコマンドが失敗したり、CAD が異常終了する可能性がある。


== *error* ハンドラ ==
== *error* ハンドラ ==

2016年10月23日 (日) 22:34時点における版

構文
(command-s [cmdname [arguments ...]])


機能
CAD コマンドと指定された入力を実行する。
  • AutoCAD 2012 より搭載


引数
  • cmdname … 実行するコマンドの名前。
  • arguments … 実行するコマンドに指定するコマンド入力。
  • command 関数の arguments 引数には、文字列、実数、整数、座標値を指定することができ、これらは実行するコマンドのプロンプト シーケンスの要求によって決まる。空の文字列("")は、キーボードで[Enter]を押すのと同じ。


戻り値
nil
  • 指定された引数を使用してコマンドを実行すると、関数から nil が返される。関数が正常に完了しなかったときは、*error* が返される。


  • MEMO: この関数の詳細について、このトピックの後の方のセクションを参照。


サンプル
; 次の例は、AutoCAD の CIRCLE[円]コマンドを実行し、直径が 2.75 の円を作成する方法を示す。
Command: (command-s "._circle" "5,4" "_d" 2.75)
nil

; 次の例は、円の中心点を入力するように求めるプロンプトをユーザに表示する方法を示す。
Command: (setq cPt (getpoint "\nSpecify center point: "))
(5.0 4.0 0.0)

Command: (command-s "._circle" cPt "_d" 2.75)
nil

; 次に、command-s 関数を使用したユーザ入力のプロンプトの不適切な使用例を示す。
Command: (command-s "._circle" (getpoint "\nSpecify center point: ") "_d" 2.75)

command 関数との違い

command-s 関数は command 関数のバリエーションの 1 つであり、コマンド トークンのコンテンツにいくつか制限があるが、command よりも高速であり、内部ロジックが違うので *error* ハンドラで使用できる。

コマンド トークンは、command-s 関数に用意されている 1 つの引数。コマンド トークンには、文字列、実数、整数、点、図形名、一覧などを指定できる。 次の例は、AutoCAD の LINE[線分]コマンドと 3 つのコマンド トークンを示す。

(command-s "._line" "0,0" "5,7" "")

「-s」サフィックスは、指定したコマンド トークンの「サブルーチン」の実行を表す。このフォームでは、CAD は AutoLISP から直接呼び出され、指定したコマンド トークンは、メインのドキュメント コマンド プロセッサとは異なる一時コマンド プロセッサで処理されて戻り、一時コマンド プロセッサは終了する。実行するコマンドは、同じ command-s 関数で開始し、完了する必要がある。

一方、command 関数は、指定したコマンド トークンの「コルーチン」を実行した状態のままになる。このとき、AutoLISP は 1 つずつトークンを評価し、結果を CAD に送信して戻り、CAD がそのトークンを処理できるようにする。次に、CAD は AutoLISP を呼び出し、AutoLISP は進行中の式の評価を再開する。このロジック フローでは、後続のトークン式で、前のトークン処理の結果を CAD にクエリーして、使用することができる。

まとめると、「コルーチン」形式のコマンド トークン処理は機能の点でより強力だが、実行中にのみ使用できるという制約がある。「サブルーチン」形式のコマンド トークン処理はより幅広い状況で使用できるが、すべてのコマンド トークンは事前に処理され、実際の実行は対話的ではない。コマンド トークンのセットが同じ場合、command-s 関数の方が大幅に高速になる。

既知の考慮事項

command-s 関数を使用する場合、次の点を考慮する必要がある。

  • 1 つの command-s 式で指定するトークン ストリームは、1 つのコマンドと入力を示す必要がある。コマンド トークンがすべて処理されたときに進行中のコマンドがあれば、そのコマンドはキャンセルされる。次に、有効ではない command-s 関数の使用例を示す。
(command-s "._line")
(command-s "2,2" "12.25,9" "")
  • すべてのコマンド トークンは、実行のために CAD に渡される前に評価される。一方、command 関数は各コマンド トークンの評価を実際に実行し、結果を CAD に渡す。CAD でその結果が処理されてから次のコマンド トークンが処理される。
  • 「Pause」コマンド トークンは使用できない。作図領域またはコマンド ウィンドウとやり取りする式を使用できるが、CAD がそれらを受け取って処理する前に、すべてが処理される。
次に、有効ではない command-s 関数の使用例を示す。
(command-s "._line" "0,0" PAUSE "")
  • 注意 : command-s 関数は command 関数と似ているが、AutoLISP 式を入力するときに進行中の CAD コマンドがある場合、U または UNDO を使用してシステムの状態をロール バックするときは注意が必要。この場合、UNDO を実行すると、進行中のコマンドが失敗したり、CAD が異常終了する可能性がある。

*error* ハンドラ

  • error* ハンドラで command 関数を使用する場合、次の方法を使用してカスタムの *error* ハンドラの定義方法を変更してみる。
  •  *error* ハンドラで command の代わりに command-s を指定する
プログラムの以前の状態を復元する必要があり、いくつかの一括コマンドを実行する一般的な *error* ハンドラの場合、(command <...>)の代わりに(command-s <...>)を指定できます。*error* ハンドラはこれまでと同様に同じコンテキストから呼び出されます。
次に、command-s 関数を使用した基礎の *error* ハンドラを示す。
  (defun my_err(s)
      (prompt "\nERROR: mycmd failed or was cancelled")
      (setvar "clayer" old_clayer)
      (command-s "._undo" "_e")
      (setq *error* mv_oer)
  )

  (defun c:mycmd ()
      (setq old_err *error*
            *error* my_err
            old_clayer (getvar "clayer")
      )

      (setq insPt (getpoint "\nSpecify text insertion: "))

      (if (/= insPt nil)
        (progn
          (command-s "._undo" "_be")
          (command-s "._-layer" "_m" "Text" "_C" "3" "" "")
          (command-s "._-text" insPt "" "0" "Sample Text")
          (command-s "._undo" "_e")
        )
      )

      (setvar "clayer" old_clayer)
      (setq *error* mv_oer)
     (princ)
  )
  • *error* ハンドラで command 関数の使用を維持する
command-s 関数の使用が必須ではない場合は、command 関数を使用できるが、ローカル シンボルにはアクセスできなくなるという欠点がある。通常、ローカル シンボルは *error* 処理の時点で AutoLISP コール スタック上にある。
次に、*error* ハンドラで command 関数を引き続き使用するために必要な事項の概要について説明する。
カスタムの *error* ハンドラで *error* シンボルを変更する場合、*push-error-using-command* 関数を呼び出して、command 関数の実行にエラー処理が使用されることを AutoLISP に通知する。
  • 注 : AutoLISP の式評価が始まるたびに、AutoLISP エンジンでは *error* ハンドラ内で command 関数が許可されないと想定する。
AutoLISP プログラムの失敗時またはキャンセル時に *error* ハンドラが AutoLISP スタック上にあるローカル シンボルを参照していた場合、それらの参照を削除するか、参照されるシンボルをグローバル シンボルにする必要がある。
AutoLISP コール スタック上のすべてのローカル シンボルはスコープ外に除外される。これは、*error* ハンドラに移行する前に AutoLISP の評価がリセットされるため。
これで command 関数を *error* ハンドラ内で使用できるようになる。
ただし、プログラムがエラー ハンドラを操作の一部として実際にプッシュおよびポップするか、他の不明な AutoLISP ロジックを呼び出している間に AutoLISP ロジックを呼び出すことができる場合、必要な手順の数がいくつか増える。
古いエラー ハンドラを復元する場合、*pop-error-mode* 関数を呼び出して、*push-error-using-command* 関数または *push-error-using-stack* 関数の呼び出しの結果を元に戻す。
ロジックに *error* ハンドラのネストされたプッシュとポップがあり、*push-error-using-command* を呼び出して command 関数を使用するように *error* ハンドラが設定されている場合、ネストされたハンドラは command 関数を使用しないが、*error* を現在のハンドラに設定したときと同じポイントで *push-error-using-stack* を呼び出すことで、AutoLISP スタックのローカルで定義されているシンボルにアクセスできる。この処理を実行する場合、以前の *error* ハンドラを復元した後に、*pop-error-mode* も呼び出す必要がある。



関連事項