View Proエリアは，SpreadJSテクノロジーを利用したWebアプリケーションです。操作感は標準的なデスクトップ版アプリケーションにかなり似ていますが，JavaScriptで動作しているため，いくつかの点に注意する必要があります。
たとえば，別のセル値を参照するセルがあり，参照されているセル自体も別のセルを参照しているような場合を考えてみましょう。
| A | |
|---|---|
| 1 | 10 |
| 2 | =関数()+A1 |
| 3 | =関数()+A2 |
| 4 | =関数()+A3 |
普通に考えれば，動的なセルの数は３個（A2, A3, A4）ですので，３回の計算をすれば良いように思えます。つまり，関数を３回だけ評価すれば良いはずです。しかし，実際に計測してみると関数は７回コールされます。なぜ４回も余計に呼び出されるのでしょうか。
ポイントは，JavaScriptの関数コールは非同期処理である，という点にあります。A1に値を入力すると，A2の関数が呼び出されます（1）。A2を参照するA3，A3を参照するA4の関数も連鎖的に呼び出されます（2, 3）。しかしながら，このタイミングで値が確定しているのはA1だけであり，A2, A3, A4は値が確定していません。見方を変えるなら，このタイミングでの２番と３番目の呼び出しは早すぎます。
(1)で呼び出された関数が値を返すと，A2の値が確定します。するとA2を参照するA3，A3を参照するA4の関数が再び連鎖的に呼び出されます（4, 5）。このタイミングで値が確定しているのはA2だけなので，５番目の呼び出しは早すぎます。
(2)で呼び出された関数が値を返すと，A3には不完全な値が代入されます。(2)の呼び出しは時期尚早だっためです。それでもA3を参照するA4の関数が連鎖的に再び呼び出されます（6）。この呼び出しも早すぎます。
(3)で呼び出された関数が値を返すと，A4に値が代入されます。この呼び出しは時期尚早だったので，値は不完全なものです。
(4)で呼び出された関数が値を返すと，ようやくA3の値が確定します。また，A3を参照するA4の関数が連鎖的に呼び出されます（7）。
(5)で呼び出された関数が値を返すと，A4に値が代入されます。この呼び出しは時期尚早だったので，値は不完全なものです。
(6)で呼び出された関数が値を返すと，A3に値が代入されます。この呼び出しは時期尚早だったので，値は不完全なものです。
(7)で呼び出された関数が値を返すと，ようやくA4の値が確定します。
まとめると，必要なのは１・４・７番目の呼び出しだけであり，２・３・５・６番目の呼び出しは無駄です。
無駄な関数コールを回避するテクニックとして，演算の順序を入れ替えることができます。
| A | |
|---|---|
| 1 | 10 |
| 2 | =A1+関数() |
| 3 | =A2+関数() |
| 4 | =A3+関数() |
これが効果的なのは，最初の連鎖ではA2およびA3の評価値が未定義（#VALUE!）であり，未定義を加算した値は未定義に決まっているので，そこで数式の評価が中断され，後続の関数が呼び出されないためです。それぞれのセルは参照先に値が代入されるたび連鎖的に再評価されますが，参照先のセルが未定義である間はそのセルに加算するべき値を求める関数の呼び出しはスキップされます。その結果，無駄な非同期コールを回避することができるというわけです。
VP SET PRINT INFOで指定するプリント設定は大文字と小文字が区別されることに留意してください。たとえば用紙サイズの「A4」や「A5」は小文字で表記する必要があります。
v17以降，ネットワークレイヤーのセキュリティが強化され，TLSの最低バージョンがTLS_1.2に引き上がられました。TLS_1.2に対応していないサーバーに対してHTTP Requestを使用した場合，エラー30が返されます。これは仕様です。必要に応じ，SET DATABASE PARAMETERでTLSのバージョンを変更してください。
v18以降，4Dが使用しているOpenSSLのバージョンは1.1.1にアップデートされました。必要に応じ，TLSのバージョンを1.3に設定することもできます。v18にはTLSv1_3という定数がないため，値の4を渡してください。
v19では，Compare stringsという関数が追加されています。既存のPositionも拡張されました。両コマンドにはStringsデーマの定数を組み合わせて渡すことができます。ただし，どんな組み合わせでも良いわけではありません。また，Compare stringsとPositionとでは，指定できる定数の組み合わせが異なります。
Unicode Collation Algorithm #10に詳述されているように，Unicodeでは文字列比較の基準が５段階に定められています。L1がもっとも緩い基準，L5がもっとも厳しい基準です。文字列を等価をみなすかどうかの決め手は，下記のとおりです。
日本語にあてはめて表現すると下記のようになります。
| レベル | 清音と濁音 | 大文字と小文字 | 平仮名と片仮名 | 全角と半角 |
|---|---|---|---|---|
| L1 | 区別しない | 区別しない | 区別しない | 区別しない |
| L2 | 区別する | 区別しない | 区別しない | 区別しない |
| L3 | 区別する | 区別する | 区別しない | 区別しない |
| L4 | 区別する | 区別する | 区別する | 区別しない |
| L5 | 区別する | 区別する | 区別する | 区別する |
各レベルは上位レベルの基準を含んでいます。つまり，L3=L1+L2+L3です。L1とL3を採用し，L2は採用しない，といったことはできないことに留意する必要があります。
この原則は，Compare stringsおよびPositionの渡すことができる定数の組み合わせにも適用されます。有効な値は，下記の組み合わせに限られるということです。
| レベル | Stringsテーマの定数 |
|---|---|
| L1 | sk width insensitive sk kana insensitive sk case insensitive sk diacritic insensitive |
| L2 | sk width insensitive sk kana insensitive sk case insensitive |
| L3 | sk width insensitive sk kana insensitive |
| L4 | sk width insensitive |
| L5 | sk char codes |
注記: 何も指定しなかった場合，デフォルトは等価性（文字列演算子の#および=）の称号順序である「L2」，つまり
となります（データ言語「日本語」の場合）。
Positionのデフォルトも同一ですが，後述するようにPositionはsk width insensitiveをサポートしていないため，振る舞い上のデフォルトは
となります。
Unicode Standard Annex #11に詳述されているように，Unicodeでは文字列の幅を下記のように分類しています。
日本語にあてはめて表現すると下記のようになります。
sk width insensitiveは，平仮名・片仮名・英数の文字列比較で全角と半角を区別しないというものです。
日本語の場合，「ぁぃぅぇぉっゃゅょ」などが小文字に相当します（捨て仮名・小書き文字）。
sk case insensitiveは，アルファベットに加え，このような文字も大文字と小文字を区別しないというものです。
データ言語が「日本語」に設定されている場合，テキスト検索用の文字列比較を使用するというオプションも設定することができます。デフォルト値は「使用する」です。
このオプションが有効にされている場合，長音記号や踊り字は単独の文字とみなされます。無効にされている場合，いずれもアクセント記号の一種とみなされます。
「清音と濁音」を区別しない場合，必然的に「全角と半角」「大文字と小文字」は区別しないことになります。言い換えるなら，「全角と半角」「大文字と小文字」いずれかを区別する場合，必然的に「清音と濁音」も区別することになります。「清音と濁音」を区別せずに（sk diacritic insensitive）の違いを区別することはできません。
日本語以外の文字列比較では，「大文字と小文字」を区別しつつ，アクセント記号の有無を無視したいことがあります。sk diacritic insensitive定数はそのような用途を想定しています。日本語の文字列比較において「清音と濁音」を区別することはまずないものと思われますが，区別しないという選択肢が用意されているのは，Unicodeの規格で日本語の濁点・半濁点をアクセント記号の一種とされているためです。
Unicodeの全角文字（平仮名および片仮名）では，濁音を単独の文字（例：「だ」 U+3060）または合成文字を使用して表現（例：「た」 U+305F+「゛」U+3099）することができます。合成文字は，幅がゼロの特殊な文字で，清音の平仮名または片仮名と組み合わせることにより，「あ゙」のような文字を表現することができます。
通常，単独文字の「だ」と合成文字を使用して表現した文字列の「だ」は，文字コードと文字数が違っているとはいえ，文字列の比較において等価とみなされるべきです。Unicode Standard Annex #15に詳述されているように，Unicodeでは，複数の方法で表現できる同等の文字列の表記を統一するためのルールが定められています。
濁音についていえば，NFC/NFKCは「できるかぎり単独文字を使用する」力学が働きます。NFD/NFKDは「できるかぎり合成文字を使用する」力学が働きます。
全角の濁音・半濁音には単独文字が存在しますが，半角の濁音は常に合成文字を使用して表現されます。つまり，NFC/NFKC正規化された全角文字と半角文字を比較した場合，文字数は全角が１，半角は２となります。NFD/NFKDでは，両者とも文字数は「２」となります。
Compare stringsは，内部的にNFKD正規化を実施しています。「全角と半角を区別しない（L1-L4）」かつ「清音と濁音を区別する（L2-L4）」文字列の比較ができるようにするためです。
注記: 19.0の初版には，sk width insensitiveで半角の濁音が正しく判定されない不具合がありました（ACI0102113）。この問題は，v19.0のナイトリービルドで修正されています。
濁音の文字数は全角と半角で異なるため，Compare stringsは内部的にNFKD正規化した文字列を比較しています。正規化された全角の濁音は，元の文字列（NFC）よりも文字数が多いため，Positionで文字列をサーチした場合，文字列が合致したとしても，返される位置と長さは信頼できない値となります。そのようなわけで，Positionは内部的にNFKD正規化を実施しません。sk width insensitiveを指定しても，半角の濁音で同等の全角の濁音をサーチすることはできないことになります。
Compare stringsおよびPositionは，新しいStringsデーマの定数をサポートしています。定数は，文字列比較の水準を指定するために使用されます。
下位の照合順序は上位レベルの基準を含んでいます。下位の照合順序を単独で指定した場合，上位の照合順序も暗黙的に指定したことになります。
Compare stringsは，全角と半角を区別せずに濁音を正確に比較できます。内部的にNKFD正規化を実施しているためです。
Positionは，全角と半角を区別せずに濁音を正確に検索できません。位置と文字数が変動しないよう，内部的にNKFD正規化を実施していないためです。
v19では，WA SET PREFERENCEの定数_o_WA enable JavaScriptが廃止され，WebエリアのJavaScriptを無効にすることはできないように仕様が変更されました。
以前のバージョンでは，システム版のWebエリアであれば，コマンドでWebエリアのJavaScriptを無効にすることができました。CEF版のWebエリアは，常にJavaScriptが有効でした。
v19では，macOS Big Surに対応するため，システム版のWebエリアがmacOS 10.10のWKWebViewにアップデートされました。WA Get page contentに相当するシステムAPIが存在しないため，内部的にJavaScriptが使用されるようになりました。また，フォントサイズを増減するシステムAPIは，Big Sur以降でなければ使用できないため，Catalina以前では内部的にJavaScriptが使用されています。いずれにしても，WKWebViewをインスタンス化した後に当該設定を変更することはできないため，下記のオプションは廃止されました。
幅が32000を超えるリストフォームをエディターで開いた場合，水平スクロールバーが表示されないことがあります。これは仕様です。以前のバージョンでは，内部的に符号付き16ビット整数が使用されていたため，フォームウィザードを使用して作成したフォームのオブジェクト座標はオーバーフローしていることがあります。そのようなフォームを現バージョンのエディターで表示した場合，正常にスクロールすることができません。多数のフィールドをリスト形式で表示したい場合，リストフォームではなく，リストボックスを使用することが勧められています。
v19では，より詳細な診断ができるようにネットワーク診断ログの精度が引き上げられました。そのため，ネットワーク診断ログにはDoReadExactlyというレポートが毎回のように書き込まれることがあります。ソケットを閉じたタイミング，あるいは他の理由でソケットのリードに失敗することは，必ずしも異常なことではありません。
ネットワーク診断ログ（データベースパラメーター79のDiagnostic log recording）は，ネットワーク関連の問題を調査することに限定して使用するべきです。早期に問題を発見するため，常時，診断ログを有効にすることは勧められていない点に留意してください。