【projectItemRenamer.jsx】総合試験 48【開発記】
一通り検証しないとならない🙄
→無限 onChenge 呼出しには排他制御で対抗よ〜🤤
デバグ
selection 代入で onChange 無限呼び出しの解決を図るお🤤
解決策
これは再帰呼出や、所謂スレッドセーフへの対策と同じになるかな🤔
解決策は幾つか有るけどこのプロジェクトで有効そうなのは
・ listener から change を取り除く
・ callback を無効にする
・専有情報を付加する
かな🤤
listener から change を取り除く、は change イベントを addEventListener した先から削除して発生しないようにするという手法😑
しかしこれは UI である DDL がどこに addEventListener しているのかを知っていて、かつ DDL オブジェクトが登録した callback を知っていないとならない🙄
callback は DDL.onChange なので取り出せる気がするけど初期値は undefined の筈なのよね🙄
対象は DDL から見てすぐ親の UI の筈だけど AE のスクリプトではシステムの UI の listener は覗く事ができないので実質この方法は実施不可って事に😞
callback を無効にする、は 一時的に onChange を null または undefined にしてしまう方法😑
ダメじゃないけどこれはメモリ管理や速度の問題でよろしくない🙄
実行文をごっそり抜いて事が済んだら差し戻す…
var temp = DDL.onChange;
delete DDL.onChange;
// ...処理
DDL.onChange = temp;
// ...
スクリプトエンジン次第だけど、 onChange へのメモリ再割当てが発生すると思う🙄
一度実行されるまでは翻訳されないとは思うけど初回起動時に仮翻訳するエンジンも有るだろうからこの再設定時に再コンパイルも走るんじゃないかな…😑
悪い選択肢ではない気がするけど処理が遅いので有名な JS の系譜なのでできれば避けたい手法かな🤔
専有情報を付加する、は簡単に言うとフラグを立てる🤤
今回の候補の中では一番原始的な方法かな🤔
誰かがファイル開いてたら他の人は使えない、所謂「排他制御」と呼ばれる仕組みで並行処理が当たり前の携帯アプリでは必須の処理法だと思う🤪
今回はこの方式を取り込もうと思うお🤤
前回のバブリングで無限呼び出しだった時も、最悪この排他制御を入れる事を考えたんだけどそっちはバブリング範囲外にする事で難を逃れたお🤪
こっちも似た方法が有れば良かったけど原因はバブリングではないので排他制御で FA 🙄
施工
まず null は処理しない、とした前回の修正は null でも処理する、に変更するお🤤
これやらないと「何も選択していない」状態になっちゃう😞
まず onChange の要因である selection をいじってる updateDDL 側から専有フラグを設定🤤
この時 onChange を発行するオブジェクトはシステムの UI である事を念頭にフラグを命名しないといけないので注意😑
要するに被らない名前にしようって話🤤
プロジェクトやオブジェクト名をくっつけたりすると効果的だけどその辺りは「グローバル汚染 回避」とかで見つかる方策を応用すると良いかな🤔
onChange で排他処理を入れる🤤
少なくともこれで updateDDL 処理中に onChange が起きても無視される様になって無限呼び出しは起こらなくなる…筈🤪
はい、いつもの………😞
とりあえずボタン実行で無限呼び出し落ちは無くなって履歴が2回分記録されたお🤤
後はこの状態で "." を選んで検索語が "." になれば勝利👇
ヨシ!👈🤪
念の為置換語の方も試したけど大丈夫だったので これにて onChenge 不具合修正 完了🤤
次回は
残りの備忘録よりも処理する事がまだ他にあるのよ?😑