一般的なエラーと警告

4D v16.3をクライアント／サーバー環境にて利用しております。
コンパイラを起動してシンタックスチェックを行うのですが、どうしても消えない一般的なエラーと警告があります。

***一般的なエラーと警告***
　　0: フォーム"[Table_1].From1"の変数"ListBox1"のタイプは変更できません。

フォーム上にリストボックスを貼り付けているだけなのですが、オブジェクト名と変数名が異なる場合によく見受けられます。いわゆるコピペで、他のフォームから持ってきたリストボックスに発生しているようにも見えますが、この一般的なエラーという項目は何なのでしょう・・・開くことも出来ませんし・・・

上記ListBox1のオブジェクト名／変数名をユニークな物に変更するとエラー自体は消えるのですが、ListBox1というオブジェクト名／変数名に戻すと再度エラーとして出てきます。同じフォームでオブジェクト名が同一運用は出来ませんし、同じプロセスでは同じ変数だと同期してしまうのですが、利用としては別プロセスの関係無いフォーム間で同じ名称を使うことに問題があるのでしょうか？

お手数ですがご教授頂ければ幸いです。

シンタックスチェックについて

シンタックスチェックのおもな目的は，コンパイルできるかをチェックすることです。おもなチェック項目は，変数型の一貫性・あいまいな型宣言の排除・ポインター使用の警告など，いずれもコンパイルモードでは致命的な問題ですが，インタープリターモードでは，はっきりいってどうでも良い問題です。また，制御フローの整合性（End ifの有無など）も，CPUアセンブリコードの出力には欠かせない問題ですが，インタープリターモードでは問題になりませんし，コンパイルに直接，影響のない構文ミス等はほとんどチェックされていませんので，コンパイルする予定がないのであれば，シンタックスチェックがどれだけエラーを返そうと，別に無視して構わないと思います。

フォームオブジェクトの「変数名」について

プロパティリストに「変数タイプ」という項目が存在しますが，これはリストに表示される項目数を絞り込むことが目的であり，変数を宣言する役目はありません。コンパイルモードでアプリケーションを使用するためには，フォームオブジェクトのデータソース（式）に設定された変数をすべて宣言する必要があります。宣言に使用するC_コマンドの「C」はコンパイルの略であり，変数の型を宣言するのはおもにコンパイラーのためなので，繰り返しになりますが，コンパイルする予定がないのであれば，フォームオブジェクトの変数をすべて宣言する必要はありません（代入文等，最初の言及で暗黙的に型が推定されます）。また，コンパイラーの「型定義を生成」ボタンで未宣言の変数を自動的に型定義することもできます。ただし，いくつかのフォームオブジェクトは，互換性のない，複数のデータソース型をサポートしているので，自動定義に頼らず，明示的にC_コマンドで宣言したほうが無難です。

代表的なもの：

ボタン・チェックボックス・ラジオボタン：倍超整数 or 実数 or ブール
タブコントロール：テキスト配列 or 数値型（リスト）
リストボックス：倍超整数（セレクション） or ブール配列（配列）

たとえば，

TabControl:=1 //#1要素をカレントに

のような代入文がコンパイラーに検出され，他に型を類推させるコードがみつからなかった場合，TabControlは数値型で宣言されてしまい，コンパイルモードでタブが表示されません。この問題は，

If (False)
ARRAY TEXT(TabControl;0)
End if

のようなコードをコンパイラーにために残しておくか，Compiler_メソッドに同等にコードを記述することで回避できます。

インタープリターモードでは，C_コマンドで宣言されていない変数の型を代入文で暗黙的に変更することができますが，コンパイルモード，あるいはインタープリターモードであっても，C_コマンドで宣言されている変数に互換性のない値を代入することはできません。プロセス変数のスコープ（可視性）は，確かに，カレントプロセスですが，変数名と型の対応関係はストラクチャファイル内で一貫していなければなりません。このことはドキュメントに明記されています。

http://doc.4d.com/4Dv16R4/4D/16-R4/Variables.300-3317965.ja.html

「作成したすべてのプロセス (ユーザプロセス) で同じプロセス変数定義が共有されます」

今回の件は，同じ変数名がセレクション型と配列型，両方のリストボックスで使用されていることが直接的な原因です。プロセスが違っているので，スコープは分離されており，したがってインタープリターモードで動かす限りは問題ありませんが，このコードをコンパイルすることはできない，という意味でシンタックスに問題があります。解決方法ですが，おそらく，セレクション型のほうは変数名で参照するコードを特に記述されていないと思いますので，そちらをフォームエディター上で「」（空欄）とすれば良いと思います。

プロセス変数について

前述したように，現バージョンの4Dでは，極力，プロセス変数を使用しないことが推奨されています。もちろん，絶対ダメというわけではなく，なるべく少なく抑えることが望ましい，という意味です。（対照的に，v16以降，インタープロセス変数は「絶対に使わない」のが原則となっています。コンパイルモードで利用できるCPUコアが1個に限定されてしまうからです。）古いバージョンで作られたフォームや，Webサービス・Web（Compiler_Webによる自動バインド）など，大量のプロセス変数が定義されているアプリケーションは，コンパイルモードで新規プロセスを起動するたびに使用/未使用かかわらず，すべてのプロセス変数を初期化する必要があり，パフォーマンスに悪影響が及びます。インタープリターモードでは，使用するまで変数は存在しないので，むしろ速いかもしれませんが，そうであったとしても，多数のプロセス変数が定義されていれば，それだけ間違って値を読み書きするリスクも増えることになります。フォームオブジェクトの変数名を「」（空欄）にしておき，オブジェクト名とポインターだけで操作すれば，フォーム上にあるオブジェクトは，フォーム内でなければ操作できないというルールが必然的に敷かれ，結果的に読み易いコードにつながります。

v11以降，DIALOGコマンドに*オプションを渡せば，1個のプロセスまたはワーカーからいくつでも同時にフォームを実行することができ，メモリやアプリケーションサーバー（クライアント/サーバーの場合）の負荷を軽減することになるので，ユーザーインタフェースはできるだけ同一のプロセスまたはワーカーで実行することが推奨されていいるわけですが，その場合，フォームにまったくプロセス変数を使用しないことが大前提になります。v12以降，フォームオブジェクト（ボタン・テキスト入力・リストボックス等）に変数名を指定することは不要になっています（オブジェクト名は必須です）。変数名のないフォームオブジェクトは，カレントフォームにスコープが限定された，いわゆるフォームオブジェクト変数 が自動的に割り当てられます。

http://doc.4d.com/4Dv15/4D/15.5/Variables.300-3577862.ja.html

miyakoさま、お世話になっております。
他変詳しい解説を頂きありがとうございます。

プロセス変数について自分の認識がズレいたと理解できました。
4Dは6.5時代から触り始めましたが本格的に常用するようになったのは2004-v11辺りから。v12で停滞していた時期が長かったのもあります。

極力，プロセス変数を使用しない

配列型リストボックスなどは現実問題としてプロセス変数を使用しない方法は無理ですよね？それとも空欄にした上で内部生成された配列を取得してポインタ経由で取り扱うことも可能？

コンパイルモードで利用できるCPUコアが1個に限定されて

インタープロセス変数はお手軽に機体毎のステータスを管理できるので、つい多用しちゃいますね。多少ボトルネックになってもウマく共有できるような仕組みがあると便利なんですけどね。

こんにちは。

他のすべての分野で徹底的にコードの最適化（メモリ足跡と速度）を追求してゆけば，やがてプロセス変数を使用していることが「ボトルネック」となります。既存のフォーム等を作り直す必要はないと思います。ただ，新しく追加するフォームについては，フォームローカル変数を主体にすると良いのではないでしょうか。

配列型リストボックスについては，プロセス変数をまったく使用しないで管理することができます。フォームエディターで列数を決めているのであれば，LISTBOX GET ARRAYSで列の配列に対するポインターが取れますし，列のオブジェクト名からOBJECT Get pointerで取ることもできます。

http://doc.4d.com/4Dv16/4D/16.3/LISTBOX-GET-ARRAYS.301-3651822.ja.html
http://doc.4d.com/4Dv16/4D/16.3/OBJECT-Get-pointer.301-3651542.ja.html

文字色・背景色・スタイル等を管理するための倍超整数配列については，プロパティリストに打ち込めるのはプロセス配列だけなので，リストボックスに非表示の数値列を用意しておき，そのフォームローカル配列をLISTBOX SET ARRAYでスタイル配列兼任にすることができます。

http://doc.4d.com/4Dv16/4D/16.3/LISTBOX-SET-ARRAY.301-3651773.ja.html

同じように，テーブル型のリストボックスでハイライトセットや命名セレクションもLISTBOX SET TABLE SOURCEを使用することでフォーム毎に分けることができます。もちろん，同一フォームを同時に2個以上，表示しないのであれば，従来どおりプロパティに打ち込んでも構いません。

http://doc.4d.com/4Dv16/4D/16.3/LISTBOX-SET-TABLE-SOURCE.301-3651808.ja.html

コマンドで動的にリストボックスを構築する場合，v14までフォームローカル変数を使用することが容易ではありませんでしたが，14R3の拡張（Nil pointerによる列の追加）により，それもできるようになりました。

http://doc.4d.com/4Dv16/4D/16.3/LISTBOX-INSERT-COLUMN.301-3651769.ja.html

インタープロセス変数に代わるもの

カスタム定数
XLIFFファイルで独自の数値・文字定数を定義することができます。On Startup等でハードコーディングされた値をインタープロセス変数に代入しているようなケースに代用できるかもれません。
http://library.4d-japan.com/REFERENCE/v13/4d-upgrade-13.pdf (p.226)

オブジェクト型のプロセス変数
READ ONLYで良いのであれば，プロセスやワーカーを開始するたびに，かつてインタープロセス変数だったものを引数として渡すことができます。その場合，プロパティ名にかつての変数名を流用できるかもしれません。

New shared object
READ WRITEアクセスが必要であれば，Use/End use構文を検討することができます。
http://doc.4d.com/4Dv17/4D/17/Shared-objects-and-shared-collections.300-3730713.ja.html

Storage
他に手段がない場合，検討することができますが，パフォーマンス等に響きますので，できる限り，使用は慎重に決めたほうが良いと思います。
http://doc.4d.com/4Dv17/4D/17/Storage.301-3730714.ja.html

miyako様、お世話になります。これまた詳細な情報ありがとうございます。
コンピュータの性能が良くなった（クライアント8GBメモリ標準とか）事にかまけて、手抜きコーディングしがちですが、プロセス変数は最近意識して使用を控える様になっております。

ただ話は少し逸れますが、それとは別に、v12 -> v16という流れで特に組み込みレイアウト（アウトプットフォーム）の動作の重さが理解できないでおります。あまりにも動作に支障が出る部分はリストボックス（セレクション型）に置き換えましたが、単純なリスト表示にそこまでコストをかける気にもなれず・・・困った話です。

インタープロセス変数が〜とか、プロセス変数を控えた方が〜とか、いうレベルを遙かに超えて重くなっている表示に、v16でデータベースの根本部分がいかに練られて高速になったか？はユーザーには関係無く、重くなった＝使いにくい＝前の方が良かったという言葉が刺さって参ります(^^;

これが複雑なレイアウトであれば致し方ない部分もあるかと思うのですが、フラットな設計の一覧を表示しているだけの表示スクロールが著しく遅くなっており、解決策はないものか？悶々とする日々で、最適化を追求する云々以前の所で足踏み状態ではございます。よい解決方法があれば良いのですが。

「昔」の4Dは，リストフォームの表示を更新するときに，ビットマップの描画コンテキストを開き，すべてのオブジェクトをいわゆる「ドット絵」として描画していました。そのような手法は，パーソナルコンピューター初期のアプリケーションでは普通でしたが，OSの進化に伴い，あまり推奨されないものとなっています。システムレベルで提供されるサービス（高解像度表示・文字入力補助など）などの恩恵にあずかることができないことは，その理由のひとつです。

現在の4D（macOS, 64ビット版）は，Cocoaという標準的なフレームワークにUIの大部分を委ねています。従来のように「フォーム」という1個の大雑把な描画領域をシステムに対して宣言し，その内部処理をすべた終えた後の画像をシステムに返すのではなく，ウィンドウ内の個別のフォームオブジェクトすべてを個別の「ビュー」オブジェクトとしてインスタンス化し，それぞれの処理をCocoaに任せているということです。「リストフォーム」は4D独自の概念であり，システムの標準オブジェクトではないので，画面全体が多数のビューで構成された複雑なUIにならざるを得ず，スクロール等の処理には，多くの場合，ウィンドウ全体の大規模な再描画が関わっています。反面，ラジオボタン等のクリックでアニメーション（フェードイン）が発生したり，タブ移動で滑らかな水平スクロールが発生したりもするのですが・・。

「フラットな設計」のリストフォームが遅い，とのことですが，どのように最適化できるのかは，実際のコードをみなければ，なんとも言えないところです。

miyakoさま、いつも丁寧にありがとうございます。
他から問題に挙がっていない様でしたら、当方独特の問題なのか？もう少し試行錯誤したいと思います。

72dpi前提の描画が、解像度可変になったからといって、昨今のCPUリソース及び2Dグラフィック性能を考えるとそこまで大きな要因のようにも思えない部分もあります。となれば、リストフォームの描画をOSではなく4D独自に行っている描画部分に起因する問題の様にも感じます。

特にOn Display Detailを見ると初回表示完了まで行数×２回イベント発生しますし、画面の更新が不要なスクロールでも行数分のイベント処理がされるところなど、結構重たい描画処理をしてるのかなぁとは感じております。

極端に遅くなる時は、上記のイベントで行毎にクエリを発動するようなケースや行の色をステータスに応じて変えたい時などなのですが、v12時代には問題にならなかった動作がv16では重くなっておりますので気になっておりました次第です。オンメモリの配列使用するとかまた色々試してみたいと思います。