【projectItemRenamer.jsx】二次調整 41【開発記】
今回の概略
見るべき場所はわかったけどまだ原因が特定できない…😞
#jsx #開発記
#ExtendScript #AfterEffects
作業準備
忘却分実装
定義新式化
Event,EventTarget
ライブラリ調整
一次調整
UI 定義 obj 調整
UI 生成再構築
二次調整 ←今ｺｺ
UI 追加
結果一覧 CSV
ラベル対応
第2層改装
ローカライズ対応
OTSParser 改
総合試験
最終調整
公開準備
----備忘録
optname と options をもっと上位で定義してその参照に置き換える
「いくない」(及び要修正)の排除
MAIN,EXE の配置再考
背面に送れない…？
plist を MAIN プロパティに足す
jsx 再実行で閉じれない
ボタン及びショートカットによる終了の実装
_debug とかのグローバル変数消す
UI オブジェクトの登録方法が忘れるとどうにもならないのでもう少し高級化したい
UI 生成方法の改善
環境読込でパネルを表示してから状態復帰する件
UI とかの app 固有は collect みたいな BridgeTalk の振り分け
BridgeTalk.appName をどこか共通で使える場所に確保( global 参照と関連)
global に定義した UI の参照いくない
nameReplacer が candidate を呼ぶ為の options 設定を UI 設定側と一元化
PrefsRestorater と NRHistories の連携が取りにくい
restoreList のクラス化
インスタンス参照可能にしている辞書を辞める
escapeDic のインスタンス参照廃止
tokenTypeDic のインスタンス参照廃止
FileState.errCode のインスタンス参照廃止
FileState.errDic のインスタンス参照廃止
所属ライブラリの調整
ファイル系は PREF から FILE へ
イベント駆動型でスコープ外変数の参照を減らす
ラベルカラー対応
第2層 3D レイヤー
ソロスイッチ
機能ボタン配置 ( ver 20230317_00 で断念した margine 問題)
第2層ラジオボタン化
listToCsv
ローカライズテキスト対応？
ローカライズの書式を一般的な物に修正したい
OTSParser 改
OTSPElement の property の幾つかが [PNAME.????] になってるので直値にする
全部やる必要は無いけど nodeValue とかは直の名前なので統一するという意図
UUI 整備が一段落したらここで全体の構成に手を入れようかな🤤
現在では jsx 用の、プロジェクト名変数に全部突っ込んで obj に参照を入れて賄っていたけれどオブジェクトとして new して走らせる形に変更🤔
このオブジェクトに _debug だとか _global の参照だとか BridgeTalk.appName だとかを持たせる、と🤤
所謂 main プロセス用オブジェクトかな🤔
それとは系譜を別として _zlib が有って2系統のオブジェクトやライブラリが有って _zlib は main は参照しない様に作る😑(当然ね
STAT,INFO のコールバック統合、イベント駆動型のスコープ外参照削減とかもここでできると良いかな🤤
題目は「二次調整」🤤
ここは一次調整よりも時間掛かると思う😑
値だけの history と同等の辞書を作る✅
buildUI 前に環境読込する✅
環境読込オブジェクトを作ると読込するのを任意動作に修正✅
(blueprint 版 UISC を作る)(BPSC?)✅
BPSC 経由で blueprint へ反映
└辞書を使って plist 作成に書換え
現在の plist への環境読込は削除(無効化)
前回の粗筋
怪しいと思える場所の手がかりが掴めない…😞
パネル復元
不具合の手がかりを求めて更なる調査へ…😑
で、前回の↑を記事書きながら確認したのもあるんだけどぼんやり「どこ見たらいいかな」とか考えてたら気がついたのよ🤔
「 child の中身、辞書じゃなく普通の配列じゃん？」って😑
restorePrefr に作った設計図への反映は参照方法を間違えて壊してるって事だからそこを見ればいいのでは？って話🙄
普通に考えたら新しく足したとこをまず見ろよってその時ようやく気付いたっていう😞
「わからなくなったら一旦離れる」
開発にはよくあるのよね…ずっと考えてても解決策が出ないんだけど一旦そこから離れると浮かぶ事が🤪
過去の開発記でも次の時に解決策や調査の足がかりを掴んでる事が有ったから適度に思考を終了するのは悪くないんだろなって思う🤤
初っ端 for は in で大丈夫…と😑
この辺りまでは まだ大丈夫…🤔
UI の種類で分岐が要ると思って入れておいた type の有無だけど結局使ってないとかとか🤪
初回は window.bounds だったので特に問題も起きず…😑
2つ目は検索語の edittext で初期値と保存値が異なっていて処理後はちゃんと書き換わってるから text も大丈夫…😑
という事はそれ以外の設定の default がおかしい…？🤔
検索語の次は置換語だから次の次かしら🤤
発覚😑
pt_ti_dl は selection を保存するけど見ての通り properties じゃなく直接設定項目に含まれてるお🙄
他にも bounds と text も直指定だけどそれは処理済み…という事は直指定系をひとまず加えた方が良いかな🤔
でも他は location , size だから壊れる様な値じゃないと思うんだけど…😑
これで残ってる value と listbox の preferredWidths が期待通りか確認しようかな🤔
selection は初期値も保存値も 0 なので正しく動いてるかは良く分からんぽん🤪
checkbox だと value が湧いてきてる…😞
一度 properties にならないヤツを確認した方が良いかなこれは🤔
処理を探していたら preferredSize がかなり特殊な設定をしてるのを発見…😞
………
ふと、これって default で properties に入れてるけど 全部直下に突っ込めば同じになるのでは…🤔
つまり…こう？🙄
ちゃんと元の設計図も書き換わってるから想定通りかな…？🤔
じゃぁこのまま…👇
………😞
長い戦いになりそう…😭
次回は
はてさて、一体どこのプロパティ処理で壊れてるのやら…🙄
この記事が気に入ったらサポートをしてみませんか？