4D v16.3シンタックスの詳細 |
||
|
4D v16.3
シンタックスの詳細
シンタックスの詳細
コンパイラは、4Dコマンドの通常の構文ルールに従っていることを期待します。コンパイルのためにデータベースを特に変更する必要はありません。 とはいえ、この節ではコマンドについての注意点や詳細について項目別に説明します。
文字列に対して処理を行うコマンドでは、Character code関数のみが特段の注意を必要とします。インタプリタモードでは、空でない文字列や空の文字列をこの関数に渡せます。 SEND VARIABLE(variable) コマンドに渡す変数の型は、常に同じ型でなければなりません。変数のリストをファイルに送る場合を考えてみましょう。誤ってデータ型を変えてしまう恐れを取り除くため、送信する変数のデータ型をリストの先頭で指定することをおすすめします。そうすると、これらの変数を受け取る際には、常に最初にインジケータが返されることになります。RECEIVE VARIABLEコマンドを呼び出したら、Case of文を使用して、次から受け取るデータを処理できます。 例 SET CHANNEL(12;"File") Field(フィールドポインタ) または (テーブル番号;フィールド番号) コンパイラでは、これらの関数から結果のデータ型を決定できません。このような場合は、コンパイラコマンドを使用して明確に定義してください。 Open document、Append document、Create Document関数によって返されるドキュメント参照番号のデータ型は時間型です。 Mod (value;divider) Variable:=Mod(25;3) または Variable:=25%3 コンパイラはこの2つの式を区別します。Mod関数はすべての数値に使用できますが、%演算子は整数と倍長整数にしか使用できません。%演算子のオペランドが、倍長整数データ型の範囲を越えた場合には、返される結果は保証されません。 IDLE IDLEコマンドは例外処理を行うために4Dランゲージに追加されました。ON EVENT CALLコマンドを用いる場合は、必ずこのIDLEコマンドも使用してください。 このコマンドはイベント管理命令として定義することができます。 4Dのカーネルだけがシステムイベント(マウスクリックやキー操作など)を検知できます。ほとんどの場合、カーネルコールはコンパイル後のコードそのものによって起動され、ユーザに対しては透過的です。 他方、4Dがイベント待ちループなどの中でイベントの受信を待っている場合はカーネルコールがないことが明白です。 `「MouseClick」メソッド この場合、IDLEコマンドを次のように追加します。 `「Wait」メソッド このコマンドは、エラー処理プロジェクトメソッド内でのみ使用してください。これは4Dで使用した場合とまったく同じように動作しますが、EXECUTE FORMULA、APPLY TO SELECTION、APPLY TO SUBSELECTIONコマンドから呼び出されたメソッド内の場合は例外です。このような状況は避けた方がよいでしょう。 コンパイラが配列のデータ型を決める際に使用する4Dコマンドは、以下の7種類です。 COPY ARRAY(source;destination) COPY ARRAYコマンドは2個の配列型の引数を使用します。引数の一方がどこにも定義されていないと、コンパイラは定義されている方のデータ型から未定義の配列のデータ型を決定します。
コンパイラはデータ型を厳密にチェックするので、COPY ARRAYコマンドは同じ型の配列間で行わなければなりません。このため、整数と倍長整数と実数、あるいは、テキスト配列と文字配列で文字列の長さが一定でない場合等のように、型の似ている配列間のコピーをする際には要素を1つずつコピーする必要があります。 $Size:=Size of array(ArrInt) 処理中に配列の次元数を変更することはできませんので、注意してください。1次元配列を2次元配列にコピーすると、エラーメッセージが出力されます。 4Dのインタプリタモードと同様、これら4つのコマンドでは配列の定義は要求されません。型が定義されていない配列にはコマンドで指定した フィールドのデータ型が割り当てられます。 SELECTION TO ARRAY([MyTable]IntField;MyArray) "IntField"が整数フィールドの場合、"MyArray"は整数配列になります。 配列が定義されている場合は、フィールドと同じデータ型になっているかどうか確認してください。整数、倍長整数、実数は似ていますが、同じ型ではありません。 テキスト型のフィールドについても同様で、宣言された型が優先されます。 LIST TO ARRAYおよびARRAY TO LISTコマンドに使用できる配列は次の2種類だけです。
ポインタについての節で説明したように、配列を定義するコマンドの引数にポインタ参照が使われていると、コンパイラは型の矛盾を発見できません。 SELECTION TO ARRAY([Table]Field;Pointer->) Pointer->が示すのが配列だとして、コンパイラは配列の型およびフィールド型をチェックすることができません。型の矛盾が起こらないようにするのは、開発者は気をつけるべきです。ポインタが示す配列を必ず定義してください。 データベースで、ローカル配列(定義されたメソッド内のみで有効な配列)を使用している場合は、使用前に明確に宣言しておく必要があります。 ローカル配列を定義するには、ARRAY REAL、ARRAY INTEGERなど、配列を定義するコマンドを使用します。 例えば、プロシージャで10個の要素を持つローカルな整数配列を作る場合、次のようなコマンドを使用前に定義しておきます。 ARRAY INTEGER($MyArray;10) Get pointer(varName) ポインタの配列を初期化する場合、配列の各要素はそれぞれ与えられた変数を表します。 ARRAY POINTER(Arr;12) また、以下のように書くこともできます。 ARRAY POINTER(Arr;12) この処理が終了すると、各要素が変数V1からV12を指すポインタの配列ができます。 この2つの書き方は、両方ともコンパイルできますが、他の場所で変数V1...V12の型が明らかにされていないと、コンパイラはデータ型を決定できません。そのため、このような変数は別の場所で明示的に使用するか、または定義する必要があります。
C_LONGINT(V1;V2;V3;V4;V5;V6;V7;V8;V9;V10;V11;V12)
V1:=0 コンパイルされたデータベースの変数のデータ型は1つだけなので、この関数は不必要に思えるかも知れません。しかし、ポインタを 使用する際、この関数が役立ちます。例えば、ポインタが参照する変数のデータ型を知りたい場合、ポインタの性質上、指されているオブジェクトがわかりにく い場合があります。 EXECUTE FORMULAコマンドは、インタプリタモードでは有効ですが、コンパイルモードではその利点を活かすことができません。 i:=FormFunc これは、以下ように書き換えることができます。 i:=FormFunc また次の例では、 $Num:=SelPrinter ここでは、EXECUTE FORMULAコマンドをCase ofに置き換えることができます。 Case of EXECUTE FORMULAコマンドは常に置き換えが可能です。実行するメソッドはデータベースのプロジェクトメソッドのリストから選択されたもので、その数には限りがあります。このため、EXECUTE FORMULAコマンドは必ずCase of文や他のコマンドで置き換えることができます。さらに、コードの実行速度はEXECUTE FORMULAコマンドよりも速くなります。 これらのコマンドはデバッグ処理の段階で使用します。コンパイルされたデータベースでは機能しません。コンパイラはこれらのコマンドを無視するので、メソッド内に残しておいても問題ありません。 Undefined(variable) コンパイラではコンパイルモードの変数は必ず定義されます。データ型は、コンパイルが完了するまでに設定されます。このため、引数が渡されると毎回Undefined関数はFalseを返します。 注:アプリケーションがコンパイルモードで実行されているかどうかはIs compiled mode関数を呼び出して確認してください。 インタプリタでは、LOAD VARIABLEコマンドの実行後にUndefined関数を使用して変数が未定義かどうか調べることにより、ドキュメントファイルの存在の有無をチェックできます。コンパイル後はこの方法を使用できません。Undefined関数が常にFalseを返すからです。 このテストはインタプリタでもコンパイル後でも次のようにして実行できます。
メソッドは以下のようになります。 Var1:="xxxxxx" インタプリタモードでは、この関数には次の2つのシンタックスがあります。 したがって、コンパイル後はテキスト、ピクチャ、BLOB、配列型の変数を除き、CLEAR VARIABLEコマンドで変数のメモリを解放することはできません。 配列の場合、CLEAR VARIABLEコマンドは、要素数が0の新しい配列の定義を意味します。 ARRAY INTEGER(MyArray;0) 2番目のシンタックスCLEAR VARIABLE("a")は、コンパイラが名前ではなくアドレスで変数にアクセスするためコンパイラで使用することはできません。 以下のコマンドには、共通する特徴が1つあります。これらのコマンドでは、最初に省略可能な引数[テーブル]があり、2番目の引数にポインタを使用することが可能な点です。 コンパイルモードでは、省略可能な[テーブル]引数を扱うことが可能です。しかし、これらのコマンドに最初に渡された引数がポインタの場合、コンパイラはポインタが何を参照しているのかわからないため、コンパイラは、最初の引数をテーブルポインタとして扱ってしまいます。 QUERYコマンドのケースで考えてみましょう。シンタックスは以下のとおりです。 QUERY(PtrField->=True) コンパイラは2番目の要素内でフィールドを表す記号を探します。しかし、“=”の記号が見つかった段階で、コンパイラは、これの関数式を判別できないため、エラーメッセージを出力します。 曖昧にならないようにするためには、以下のいずれかのように記述することができます。 QUERY(PtrTable->;PtrField->=True) または QUERY([Table];PtrField->=True) テーブルを省略しないことで、曖昧さを避けることができます。 ポインターを使用する際、これらのコマンドには、最初の引数が [aTable]で、2番目の引数がどちらも任意であるという共通性があります。このコンテキストでは、内部的な理由から、コンパイラーはポインターを返すコマンド(例:Current form tableなど)を直接引数として渡すことを許可しません(エラーが発生します)。 例えばFORM SCREENSHOTコマンドなどもこの例にあてはまります。以下のコードはインタープリタモードでは動きますが、コンパイル時に除去されます: //コンパイルエラーをトリガー この場合、このコードに中継用の変数を用意してからコンパイラに渡す事ができます: //コンパイル可能な同等のコード 独自の4DK#リソース(定数)を作成する場合は、必ず数値の型を倍長整数(L)もしくは実数(R)に、文字列の型を(S)に設定してください。その他の型では警告メッセージが表示されます。
参照
|
プロパティ
プロダクト: 4D
履歴
ARTICLE USAGE
ランゲージリファレンス ( 4D v16) |