JDK バージョン
Ver1.4.0 では jdk1.7.0_13 以上にて動作いたします。
LookAndFeel
基本的に Metal での動作保証となります。
本製品では、UIにて制御している部分の拡張は行わず、LookAndFeelの切替が行えるように考慮されていますが、 LookAndFeel の仕様により、画面レイアウトや動作が変わる場合がございます。
Metalにて正常動作をする設定である限り、製品での不具合としての修正は行いませんので予めご了承ください。
IMEの設定
Data Management Consoleのデータ型により自動的にIMEの設定が行われます。
IMEの設定が行われるタイミングは「フォーカス取得時」と「実行リスト処理完了時」になります。
ボタン系コンポーネントについてはデータ型に関わらず常にIME設定なしになります。

Javaのハードコーディングにて可能である場合
1. GUI部品以外のクラス作成の場合
  ロジッククラスを作成することにより実装可能です。
2. GUI部品に対してメソッドにて(SwingAPI)アクセスする場合
  ロジッククラスを作成することにより実装可能です。
3. GUI部品のクラス自体を作成(or継承) しないといけない場合
  実装ができません。
  部品作成を請け負う事も可能です。(別途費用必要)
Javaのハードコーディングにて不可能な場合
実装は不可能です。

JavaClientでは、処理部品(ロジッククラス)を設定できるイベントを提供しています。
Before(フォーカス取得時) 、After(フォーカス紛失前) というタイミングにて、処理部品を挿し込みします。
これら標準提供しているイベントのタイミングでは、処理の順番がシーケンスで必ず発生するという仕様にて作成・制御されています。
(言葉を変えると、Before の発生と After の発生順序が逆にならないように、また入れ子で動作しないように制御されています。)

また、定義された処理を実行するスレッドは Swingメインスレッド上になります。
これにより、Afterのタイミングにてフォーカス移動は不可という指定をすると、Tabやマウスクリックでフォーカス移動しようとしてもフォーカスは移動できない(クリックは反応しない) 制御を実現しています。

時間のかかる処理 (たとえばサーバアクセスなど) 中も、続けてGUIの操作(描画処理を含む)を有効にしたい場合には、処理自体を別スレッドにて処理を行う方法のご検討をお願いします。

処理中の MOUSE_PRESSED のイベントは無視されます。
これは、Swingの EventQueueでは処理中の MOUSE_PRESS(ボタン押す),MOUSE_RELEASE(ボタン離す) のイベントが EventQueueに溜まった場合、同時に KEYイベントが溜まっているている状態ではイベント発火順番が実行した順番と異った順番になります。
これが原因での問題が発生しないように製品にて制御しています。

補足
JDK1.4以前の場合、処理中に溜まった EventQueue の内容の順番やAWTEvent内容に不具合があるため、先行入力不可という仕様にすることにより、JDK不具合を回避しています。
JDK1.5.0_02以降ではその不具合が解消されているのが確認できたため、キーボード先行入力が可能な仕様に変更されました。

標準提供しているイベントのタイミング以外でのハンドリングでは、通常のSwingのコーディングと同じように GUIコンポーネント部品に対して add***Lisnter によりイベントをリスナーする事が可能です。
ただし、その場合では JavaClientエンジンでは上記の制御を行わないのに注意してください。 (つまり、処理順番が正しく実行されるとは限らない)

3-2. フォーカス制御

フォーカス移動の動作についても実行エンジンにて制御を行っています。
処理中でのフォーカス移動(Component#requestFocus() など) が発生しても無視され、処理終了後、適切なGUIコンポーネントにフォーカスが移るように実行エンジンにて制御されます。

処理中でのフォーカス移動(Component#requestFocus() など) の処理は Swingからの実行、ロジッククラスからの実行ともに無視されますのでご注意ください。
ロジッククラスからフォーカス移動先を指定する場合には SetFocus (標準ロジッククラス、メソッド) をお使いください。

適切なGUIコンポーネントとは、
項目チェックエラー発生時はフォーカス移動なし、
処理中に "フォーカス移動指示" があった場合には指示のコンポーネント、
無い場合にはクリックされた(MouseClick) もしくは次のコンポーネント(TabKey) になります。

このように、最小限のフォーカス移動に押さえることにより、無駄なフォーカスイベントを発生しない (=無駄な Before,After の実行を行わない) ように制御されています。

4. 設計方針について

4-1. 作成する処理部品

JavaClientでは、処理部品を作成し各種イベントに設定することにより動作いたします。
どのような処理を、どのような部品にて作成すると一番好ましいのか？という観点にてご説明します。

入力された値のチェック
テキストフィールドなどにて入力された値が正しいかどうかのチェックを行う場合、チェッククラスにて処理をコーディングします。
標準にて提供しているチェックの内容は Data Management Console にて登録されたデータの型、長さなどになります。
標準以外のチェックを行いたい場合には、チェッククラスを独自に作成します。
チェッククラスは、データ単位毎に設定が可能です。複数の画面にまたがって同じデータ(チェック内容)を使用することが可能です。
全ての画面に渡ってどのようなデータ(チェック内容)の種類が必要かを "設計の最初" に洗い出すと後の設計がしやすくなります。
表示データをフォーマット
データを分かりやすいようにフォーマットして表示したい場合にはフォーマットクラスを使用します。
フォーマットクラスでは、GUI部品にて表示時にはフォーマット形式にて表示しますが、内部データには影響与えません。
つまり、内部のコーディング(ロジッククラスなど)ではフォーマット有無意識せず、本来のデータ形式にてやり取りを行う事ができます。
標準にて NumberFormat(数値をカンマで桁区切りにする) と DateFormat(日付形式にする) ものが提供されています。
フォーマットクラスを独自に作成することも可能です。
上記以外の処理
上記以外の処理を実装するためには共通ロジッククラス/クライアントロジッククラスを使用します。
共通ロジッククラス/クライアントロジッククラスは標準提供している部品もいくつかありますので、標準に無いものを独自に作成します。
ロジッククラスを Operation Management Consoleにて登録すると、全ての画面にて設定したロジッククラスを使用できるようになります。
設計時には、各画面共通で使用するロジッククラスを始めに洗い出すとよいでしょう。
複数画面にて共通使用する処理
ロジックをライブラリとして使用する場合にはロジッククラスを一つ作成し、各画面にて使用します。
画面の一部分(GUI部品を含む)を共通的に定義するには ClientJava / 画面インポートの機能が使用可能です。

4-2. 部品の設定タイミング

処理種類として、"処理時間が少ないもの" と "処理時間がかかるもの" が存在すると思います。
後者の "処理時間がかかるもの" の例としてはサーバーとアクセスしてデータを送受信するのようなものになります。

"処理時間がかかるもの"の処理は、基本的にボタンコンポーネントの Afterイベントに設定するのをお勧めします。

テキストのAfter などのフォーカス紛失前のタイミングの場合、操作者にとってそのタイミングにて処理が入っているかどうかの認識が出来ないため、処理中の状態が「フリーズした？」と思われる事も発生します。
逆にボタンのAfterに "処理時間がかかるもの" を設定すれば、「このボタンを押下されたときに何かの処理が走る」ということが認識できるため、操作者にとってより親切なインターフェースになります。

4-3. テスト方法

アプリケーションを作成するに当たって、テスト方法を "始めに確立" しておく事はとても重要です。
VisualFrameの場合、以下のように大きく分けることが出来ます。

処理部品であるロジッククラスの「単体テスト」
作成画面を動作する「全体テスト」

Javaのコーディングが発生するのは、ロジッククラスのみになりますので、「単体テスト」完了にてハードコーディング部分のテストが完了になります。
「全体テスト」では、ツールにて設定した定義が正しいかどうかのテストになります。

ロジッククラスでは入出力のインターフェースが固定で統一されていますので、JUnit によるテスト自動化なども容易に行う事ができます。
(Developer'sWorksにてサンプルを提供しています。)

5. 実行イメージ

実行すると、指定されたデスクトップ(画面メニュー)が表示されます。
デスクトップのメニューより、Client Application Management Consoleにて定義したフレーム(Window) が表示します。
(デスクトップにはメニューの他に初期表示の設定、定義情報事前ロードなどの機能があります。)

フレームには、アイテムと呼ばれるデータとコンポーネント保持しているオブジェクトが存在します。
ロジッククラスへの入出力引数は、このアイテムを受け渡ししますので、ロジッククラスからはデータ情報と GUIコンポーネント情報の両方が取得・設定可能です。

内部データをロジッククラスより変更した場合、自動的にGUIコンポーネントに反映されるため、開発時には "データの状態"のみ意識することになります。
GUIでの表示の際、フォーマットクラスを指定することができます。日付の場合パターン"yyyy/MM/dd"を指定することにより「20010101」→「2001/01/01」、数値の場合パターン"0.###E0 m/s"を指定することにより「20000」→「2E4 m/s」と表示形式をフォーマットします。入力する際には元の形式にアンフォーマットします。
このフォーマット機能を実行しても内部データは影響しません。つまり、フォーマットされるのはGUIコンポーネント上の表示のみになります。
データ型毎に IMEの自動設定、文字水平位置の自動設定が行われます。

データ型毎にデータチェック方法の指定が可能です。
標準チェック内容は、Data Management Consoleの内容(長さ、型など)に基づいたチェックをおこないますが、独自でチェッククラスを作成して登録する事も可能です。
チェックはフォーカス紛失時に動作し、チェックエラーの場合にはメッセージダイアログ表示 + フォーカス移動不可状態になります。

上記イメージの該当部分のリンクより各説明が表示されますので、詳しくはそちらをご覧下さい。

6. 開発手順

事前にロジッククラスの作成・登録、基本データ定義などを行っておきます。
画面イメージ作成は、製品付属のGUIデザイナを使用する事で簡単に行うことが出来ます。
その他画面定義では、データの設定、データとコンポーネントとの紐付け作業、イベント時実行モジュールの設定などを行います。
FrameRunner の画面単体テスト用 FrameRunner を使い、画面の動作テストを行います。
実行、デバッグ、定義情報再設定を繰り返しながら完成していきます。デバッグには、使用データ一覧表示や、ロジッククラスの実行ログなど参照が可能です。
上記イメージの該当部分のリンクより各説明が表示されますので、詳しくはそちらをご覧下さい。

JavaClient概要

1. 動作環境

2. 標準機能以外の実装可・不可の判断

3. Swingとの動作差異について