G3018_グリッドビューの実験②
2025年3月9日
16:47
G3018_pc_goma_note_grid_view_mobile_alignment_2
下記はプロジェクト圧縮ファイルのリンクです
Version:0.9 StartHTML:00000000 EndHTML:00000000 StartFragment:00000000 EndFragment:00000000 G3018_プロジェクト
前回までのあらまし
- スマホアプリのための、キーワードデータを作成しました
- グリッドビューにデータを代入すると同時に、キーワード分解する機能を臨時に仮設していました
- キーワード分解の機能は順調で、スマホの運用も順調です
- しかし、キーワードの件数が、特に英単語検索のキーワードが増えたことで、パソコンからスマホにデータコピーする時間が大変長くなっています
- スマホからパソコンへのコピーは一瞬で終わるのですが、スマホへのコピーは遅いです
実験スケジュール
- 分解作業は、スマホ側のプログラムに移行します
- グリッドビューのパッケージ化を推進します
- 固定されたグリッドビューを3個配置し、メイン、サブ、詳細という3階層のデータを扱えるようにします
- モデルケースとして、スマホ日誌に使ったデータを表示し、登録できる仕組みを作ります
ひとりごと
- 定義登録と、データ入力を同じフォームで実行することは、コードを複雑にしているのではないか？
- 使いやすさと作りやすさを両立できるだろうか？
- そもそも、前世で達成できなかった目標が、能力の衰えた今世で実現できるのだろうか？
忘れていることを思い出す
- 以前のバージョンでは、グリッドフォームをグローバル変数の配列に展開していましたが、今回はテキストファイルに展開します
- これに伴い、多くのグリッドフォームを比較的少ない労力で扱うことが出来るかもしれません
- しかし、処理速度は犠牲になります
以後は筆者の能力限界を超えて、複雑になりました
- メイキングは能力不足の為できなくなりました
- プロジェクトコードを公開し、解説に徹するものであります
- 下記は、グリッドのカラム配置を定義するファイルの定義体です
- 表示するだけなら、名称、長さ、少数だけあれば成立します
- 漢字や表記は、データ入力する場合に利用する要素です
- 表記の事例としては、通貨などですが、すべてを網羅することはありません
- ユーザの立場で、業務に利用されるもののみ実装されると理解しています
上記は、グリッドのカラム配列を定義する画面です
- 複雑にならないため、グリッド配置とファイルのレコード配置は一致します
- 将来、非表示項目は作れても、位置を変更したりは出来ません
- システム要件に合わせたファイル構成を定義します
グリッド配置された、システム定義
- 解説の為に、見やすくグリッド配置しました
- 下記テキストデータは、メモ帳で作成しています
- 大きな障害となるのは、この定義体が不用意に編集されることは、システムに致命的であることです
保護の意味では、プログラムコードで固定することが安全ではありますが
- 他のグリッド配置と異なり、この定義体は参照頻度が桁違いに増えるので、グローバル変数配列にも展開しています
- 行の位置と役割が変更されるとデータが壊れます
- 定義体の長さは自由に変更できます
- 機能追加の為、後方にカラムが追加されることは問題ありません
- この意味では、表記1/表記2は未定義なので、自由に構成変更は可能です
- 今のところ、テキストファイルをリードオンリーにすることで保護します
- 手動でプロパティからReadOnlyにしてプログラムの読み込みには影響ありません
メモ帳で編集すると下記の表示になります
プログラムで編集すると下記エラーが出ます
★ 例外処理に任せては、更新フラグが初期化されず、アプリが起動しなくなります
そこで、グッドデータの保存箇所で禁止処理とフラグの初期化を行います
初期画面の変更は、登録関数のコード変更で行います
- 解説は出来たので、更新したら危険な、「システム定義.columntxt」の画面は非表示にします
メインタイトルの登録
- メインタイトルをグリッド側で登録できるようにしました
これからもダイナミックに変化します
- 説明のめどが出来たので、コードの先頭から流れを説明します
- メイキングではないで、コードのペーストはありません
- 公開プロジェクトをダウンロードし、解析してください
グローバル変数
グローバル関数
- コードは折りたたみしています
メインループ
グリッドデータの保存タイミングに相当悩みました
- 終了時点
- 定義モードが変化する時
- メインタイトルが変化する時
- この3か所に設置しました
グリッドのデータ入力は下記イベントを採用しました
IME制御を追加しました
グリッドデータを保存するために、更新件数パラメータを追加しました
実験結果の考察
- やはり処理速度は犠牲になりました、特に起動が遅く感じられます
- 完成に近づくと、どれだけ遅くなるのか心配にはなります
- また、3階層のグリッド表示は遅く、3秒の限界を超えそうです
- これから、メインタイトルに伴ったファイル設計を進めながら、業務処理が実現できるか実験を進めます
スマホ日誌
- スマホ日誌の運用は順調です
- 行動記録、お使いリスト、忘れ物記録、やることリスト、レシート記録などに活用しています
- 排泄記録、飲み薬、食事などの記録は、習慣化できていません
- 貢献度の低いことが要因だと分析しています
- スマホ記録と連動し、パソコンでもデータ入力できる実験をします
- 月一覧は実験出来ていますから、1週間単位で入力できる機能を実験します
確定申告
- 今年の確定申告に間に合わせるつもりで、頑張りましたが、遠く及びません
- 例年通り、エクセルで処理しました
- 通帳の入力から、集計表を作ったりして、機能評価する予定です
- 前世アプリの「クリップボード」機能は大変役に立ちました
- 今世アプリでも、実装する予定です
積算モデル
- ある業種の積算システムをこの「グリッドビュー」連結で再現できるか実験する予定です
- ほとんどが機密情報なので、公開することは出来ません
- 6本のマスターファイルと13本のテンポラリファイルを使って、見積もり明細を作成するシステムでした
- 特に12本のテンポラリファイルのフローをグリッドフローで実験する予定です
- 10万件の部材のハッシュ検索をテキスト分解で置き換えることが出来るか？など実験します
- 計算の過程、フローが目視できるなど、利点は多いと思いますが、処理速度が遅くて、実務では使えないと思います
- 実務では、遅い部分をメモリ化、コード化して、処理することにはなると思いますが、パッケージ化も可能なのではないかと思っています
- パソコンの性能アップにも期待します
- また、ファイルアクセスのオーバーヘッドを解消すべく、SSDをDRAMにごっそり転送して、ファイルアクセスをDRAM上で行うようなツールが開発されたら理想です
- グリッド丸ごとファイル保存するであるとか、それが出来れば、速度アップし、コード量も劇的に減らすことが出来ます
学習モデル
- ＡＩには届かないのですが、個人の経験をデータベース化する計画です
- 主に、認知症の進行対策として作成されます
- 個人が経験した物品リストを登録します
- 保管場所が頻繁に忘れられ、同じものを購入するというトラブルが出始めたので、在庫検索として活用します
- 電子部品の在庫数は今まで、脳内で処理していました
- １０数年前から数が把握が出来なくなり、今やあるかないかを忘れています
- 工具、日用品、ゴミの処分、回収資源、便利グッズの設計図などなどすぐ忘れるので検索できるようにします
- 物品の使用実績、マイコンに利用するＩＣやＦＥＴなどの部品の活用事例などは代表される事例です
- 修理に活用した物品とかの記録も登録しなければ失われています
- スマホで入力して、パソコンのデータベースに蓄積するという流れになると思われます
クリップボード機能の再現
- 実用性があります（改善効果が高い）ので、これの再現が優先されると思います
- 住所、氏名、よみカナ、専門用語のスペル、定型文書などが代表されるものです
- コピーペーストの工程は、マウス範囲指定、CTRL+C、コピー先への移動、CTRL+V
- CTRL+V はボタン一つで処理できるように改善しています ハードウエア処理
- グリッドに、コピーペーストしたい文字を配置しておき、マウスのワンクリックで、範囲指定とCTRL+C、アプリの最小化を一度に実行します
- コピー先の文書を表に出すために、アプリを最小化を入れていますが、並べて表示している場合は最小化を停止します
自作アプリの限界
- 主たる要因は、筆者の能力不足なのですが、前世アプリでも滞ったのが、定義体の保護、定義体の変更に連動してデータを変更する機能が作れなかったことです
- ここを実現すると、商品化が可能なのですが、増加するコード量、バクの増大、検証パターンの増大などは、個人の手には負えません
- 前世アプリでは、データの変換処理をマクロで実行すべく挑戦しましたが、挫折しています