DOWN LOAD BBS

HOME HELP 新規作成 新着記事 ツリー表示 スレッド表示 トピック表示 ファイル一覧 検索 過去ログ

ダウンロードされた「感想・質問・希望」等、お聞かせ下さい
作者の一番の励みになります。
■ 24時間以内に作成されたスレッドは New で表示されます。
■ 24時間以内に更新されたスレッドは UpDate で表示されます。

記事リスト ( )内の数字はレス数
UpDate拙作の[整形ユーティリティ]の些細な改良(7) | NomalINF_Framework の手続きリファレンス(0) | Nomal1st_Thin_INF_Framework_組み込みガイド_改訂版(0) | NomalINF_Framework HDLVAR 仕様書メモ 第2版(0) | Nomal[桐の釣魚大全]の新サイトのご案内(0) | NomalThin_INF_Framework for 桐10s/ 桐sSL / 桐sLT(2) | Nomalダブルクリック考(3) | NomalThin_INF_Framework ベータ2のご案内(58) | NomalINF_Framework の話をしよう(19) | NomalモードレスB で さよなら。モードレスB を閉じる(7) | NomalThin_INF_Framework のご案内(58) | Nomalガントチャートのベータ版のご案内(19) | Nomalガントチャートについて(1) | Nomalガントチャート試作品(30) | NomalINF_DatePicker がデートタイムピッカーに改修されました(2) | Nomal#205 INF_Framework 第3.3版 改訂版(MkII) サンプル集 for 桐10s / 桐sSL(0) | Nomal#207,206,205,204 のIPS_Framework.cmx に関して(0) | Nomalフォーム定義リストの[Webビュー]オブジェクト対応(0) | Nomal桐10s/桐s版のフラットスタイル・フォームに対応(1) | NomalINF_Framework の入門講座を公開しました(0) | Nomal整形ユーティリティ 3.91 アップデート(0) | Nomal観験桐(ダウンロードコーナー)で拙作が紹介されました(0) | Nomal#199 God_Excel_Reader アップデート(0) | Nomal#200 アイテム登録が要らないランチャー:toy_history(0) | Nomal#199 紙・神・方眼紙エクセルのデータ( .csv / .txt )を桐の表に変換するユーティリティ(0) | Nomal#197 イベント処理の整形ユーティリティ 第 3.9 版(2) | NomalINF_DatePicker.wfm/wfx の編集属性式の改修について(0) | Nomal#195 #196 INF_DatePicker.kev/.kex 共通(1) | Nomal#195 #196 INF Framework 第3.3版 INF_DatePicker(1) | Nomal#198 INF_カード 第1.0版のご紹介(1) | NomalIPS_Framework.cmd / IPS_Framework.cmx 共通(0) | Nomal#197 イベント処理の整形ユーティリティ 第 3.9 版(0) | Nomal初心者向けの一括処理のサンプルはありますでしょうか?(2) | Nomal#195 INF Framework 第3.3版 for 桐9-2012 / 桐9s(0) | Nomal#197 イベント処理の整形ユーティリティ 第 3.9 版(0) | Nomal193 クラシックUI_モダンUI_変換ユーティリティ(1) | Nomal桐でGrep10(5) | Nomal桐でGrep(桐9対応版)素晴らしい(1) | Nomal192 整形ユーティリティ(3) | Nomal190 整形ユーティリティ ビーユージー(0) | Nomal188 アップデート INF_dirでゲットだぜ(1) | Nomal187 INF Framework 第3.2版 for 桐10 / 桐10s (0) | Nomal186, 187, 188, 189 INF_Framework の潜在バグ(0) | Nomal188 イベント処理の整形ユーティリティ 第 3.5 版に関して(0) | Nomal171:toy_launcher 第 3.0 版を使ってみて(3) | NomalINF_DatePicker(カレンダー入力)(0) | Nomal177・8 INF Framework (桐10/ 桐10s・桐9-2012/ 桐9s版)(0) | Nomal182 整形ユーティリティに無害な虫がいました(1) | Nomal175:「桐でGrep(桐10対応版) 3.10版  (C)悲しげ」を使ってみて(5) | Nomal177・8 INF Framework (桐10/ 桐10s・桐9-2012/ 桐9s版)(1) | NomalIPS_form を使いこなすための手引書です(1) | Nomal176:桐でGrep(桐9対応版)(2) | Nomal174: 桐10移行計画3 (0) | Nomal173:イベント処理の整形ユーティリティご紹介(1) | Nomal「 171,172 」の、2作品、同時紹介です(0) | Nomal170:文字検索処理 Ver1.21 ご紹介(8) | Nomal169:イベント処理の整形ユーティリティ 第3.0版(1) | Nomal168:ファイル・フォルダをチェック(0) | Nomal終端行は指定できませんというエラーで苦戦!(1) | NomalA4用紙に2枚の伝票を印字したい(1) | Nomal了解しました(2) | Nomal初心者向けのサンプルは?(1) | Nomal列固定に集計関数も移動させたい(1) | Nomal桐V9 メール一斉送信 2.01 (0) | Nomal167:フォルダ毎サイズ集計(0) | Nomal桐4作品、一挙掲載(4) | Nomal162:データ管理システム(0) | Nomal160:toy_launcher(3) | Nomal161:販売部長U(体験版)」桐9-2004版(0) | Nomal159:画像管理システム for 桐(0) | Nomal140 清書ユーティリティ 第2.1版 (再)登録 (2) | Nomal158:わんたっち表形式 の登録(2) | NomalNO TITLE(0) | Nomal157:桐で「キーダウン・システムキーダウン]イベントを自由自在に制御(1) | Nomal155:桐で「麻雀牌ゲーム(四川省風)」(1) | Nomal156:桐で「トランプゲーム(フリーセル風)」(0) | Nomal154:桐で「RSSリーダもどき」(0) | Nomal拙作のライブラリのアップデートに関して(1) | Nomal153 MNU Tools フォームにメニューバー(4) | Nomal151・152 桐のツール掲載(0) | Nomal150 ウィンドウ操作プログラム(0) | Nomal149 再帰でファイル検索(0) | Nomal146〜148 ビュア3題(0) | NomalNO TITLE(1) | Nomal145 INF Tools  第1.1版のバージョンアップ(3) | Nomal144 INF Tools 第1.0版 for 桐ver.8 / 桐ver.9(4) | Nomal「マウス入力」と同時に移動もできますか。(2) | Nomal142 桐でヘルプファイルを(1) | Nomal143 桐v9 メール一斉送信 Ver.2.01(0) | Nomal「メール一斉送信]について(10) | Nomal141 桐ver8 列固定式の一覧表形式フォーム(1) | Nomal全銀フォーマット作成一括処理使わせていただきました(8) | Nomal140 清書ユーティリティ 第2.1版 登録 (8) | Nomal138 桐ver9 文字列検索 (0) | Nomal137 桐ver9 K-ba (0) | Nomalこの掲示板の XSS 脆弱性(3) | Nomal全銀フォーマット作成一括処理について(2) | Nomal固定長テキストから桐表への変換 教えてください(10) | NomalNo74 全銀フォーマット作成一括、使わせてもらいました。(1) | Nomal136 一覧表wfmの列固定もどき(改訂第2版)(5) |



■記事リスト / ▼下のスレッド
■602 / 親記事)  Thin_INF_Framework for 桐10s/ 桐sSL / 桐sLT
□投稿者/ ONnoji -(2024/12/04(Wed) 14:45:22)
    2024/12/04(Wed) 14:45:53 編集(投稿者)

    ファイナル版ダウンロードのご案内です。

    拙作webページのダウンロードコーナーでダウンロード出来ます。

    桐の釣魚大全のトップ > ワークショップ > ダウンロード

     ◇ ◇ ◇ ◇ ◇ ◇ ◇

    イベント処理のランチャー・シーカー・メッセージセンダー
    Thin_INF_Framework for 桐10s/ 桐sSL / 桐sLT
    サブセット  2024.11.20

    Thin_INF_Framework_For_Kiri10s_final.zip 約818KB

     --------------------------------------------------------------------------------
     イベント処理のランチャー・シーカー・メッセージセンダー

     Thin INF_Framework for 桐10 / 桐10s / 桐s

     By ONnoji Copyright (C) 2024

    【URL】http://silicon7565.html.xdomain.jp/
     --------------------------------------------------------------------------------

     ■ソフトの種類

     対象:桐のアプリケーション開発者

     種類:イベント処理のランチャー・シーカー・メッセージセンダー
        フォーム( .wfx )、イベント処理( .kex )、ライブラリ( .cmx )によるフレームワーク

     ■ソフトの内容

     ・フルスペックの INF_Framework から[FLD / EZW]機能を無効にした、サブセットの INF_Framework です。

     (注意)[FLD / EZW]機能とは以下の機能の名称です
        ・一覧表形式や伝票形式のフォームが、表編集のように左右スクロールします。
        ・一覧表形式や伝票形式のフォームが、表編集のように列固定出来ます。
        ・項目の表示幅をマウスドラッグで変更出来ます。

     ■Thin INF_Framework の使い方

     <ボタンの説明>

     ズームイン  … [虫メガネ(+)] / Alt + I
     ズームアウト … [虫メガネ(-)] / Alt + O
     情報     … [?]

     <制限事項>

     ・ このフォームは「サブフォーム」として利用できません

     ■解凍について

     zip形式のファイルを、任意のフォルダに解凍(展開)してください。

     <同梱ファイル一覧>

     1st_Read_Me_お読みください_Thin_INF_Framework.txt

     1st_Spec_INF_Framework_手続きリファレンス.txt
     1st_Spec_Memo_HDLLNC.txt
     1st_Spec_Memo_HDLVAR.txt
     1st_Spec_Memo_ModernUI.txt
     1st_Spec_Memo_SpinButton.txt
     1st_Spec_Memo_VK.txt

     1st_Thin_INF_Framework_HDLCOM_サンプルについて.txt
     1st_Thin_INF_Framework_HDLLNC_サンプルについて.txt
     1st_Thin_INF_Framework_Variable_Save_サンプルについて.txt
     1st_Thin_INF_Framework_組み込みガイド.txt

     INF_Framework.cmx … Rev.272
     IPS_Framework.cmx … Rev.272

     NO_EZW.kex
     NO_EZW.tbx
     NO_EZW.wfx      … サンプルのフォーム([モダン⇔クラシック]機能無し)

     NO_EZW_Launcher.kex
     NO_EZW_Launcher.wfx … ランチャー(ローンチャー:発射器)

     NO_EZW_Plus.kex
     NO_EZW_Plus.tbx
     NO_EZW_Plus.wfx   … サンプルのフォーム([モダン⇔クラシック]機能有り)

     NO_EZW_Receiver.kex
     NO_EZW_Receiver.tbx
     NO_EZW_Receiver.wfx … 受信器

     NO_EZW_Sender.kex
     NO_EZW_Sender.wfx  … 送信器

     NO_EZW_Variable_Save.kex
     NO_EZW_Variable_Save.wfx

     transaction_A.kex
     transaction_A.tbx
     transaction_A.wfx
     transaction_B.kex
     transaction_B.tbx
     transaction_B.wfx

     ユニットINF_3-3MkII_INFprcStartup_NO_EZW.txt … Thin INF_Framework専用のスタートアップ
     ユニットINF_3-3MkII_名札メイン.txt      … INF_Framework共通の[名札 メイン]部

     当該ソフトは無料で提供されるソフトウェア(フリーウェア:freeware)です。

     免責 :動作の保証はしません。各自の責任でご使用下さい。

     改造等:オリジナルの全体または部分の改造、およびオリジナルの部分的な使用もOKです。※1
     ※1:改造や流用は極めて困難ですので、ブラックボックスのままお使いになることをお勧めします。

     再配布:オリジナルの全体または部分の無償再配付はOKです。※2
     ※2:フリーソフトウェアなので価格を付けて配布しないでください。
     ただし、貴殿が開発したアプリケーションに当該フリーソフトウェアを組み込んだ場合、
     当該フリーソフトウェアを除いた部分に生じた貴殿の開発コスト(価格)は、
     (当然ですが)貴殿の裁量で自由に決めてください。

     ■スペシャルサンクス

     次の皆様のご協力・ご助言に対し深く感謝申し上げます。

     ジェダイの桐さん Akomeさん AKさん

     以上

引用返信 [メール受信/OFF]

▽[全レス2件(ResNo.1-2 表示)]
■603 / ResNo.1)  Re[1]: Thin_INF_Framework for 桐10s/ 桐sSL / 桐sLT
□投稿者/ ジェダイの桐 -(2024/12/05(Thu) 17:05:04)
    ONnojiさん


    こんにちは!


    イベント処理のランチャー・シーカー・メッセージセンダーThin_INF_Framework
    の正式リリース楽しみにしていました!


    私は現状 INF_Framework 若しくは Thin_INF_Framework でフォーム作成しています。


    今でも、メッセージのやり取りは、トレース出力をかなり使用し、どのプログラムにいるか流れを詳細に分かる様にしないと難しい部分があります。


    が、しかし、やっぱり失敗しながらでも 流れと変数の値 を確実に確認しながら使用していると、当初より流れがイメージ出来る様になってきたんですよ(^^ゞ


    不思議な物で、流れを意識しだす事で気付いた事があります。
    引数を使って、値を別モジュールに送る事で、モジュールの中身を抽象的に書けるなと。


    ほんの少しですが、構造化プログラムの考え方が分かって来たような気がします。


    以前、ONnojiさんが 1つのピタゴラスイッチを押す事で、ドミノ倒しの様に次々にピタゴラ装置が動いていく。
    この様なニュアンスの事を教えてくれました。


    メッセージの送受信が可能になった事で、ピタゴラ装置 ドミノ倒し の意味は理解出来ました。


    本当に色々とありがとうございましたm(__)m


    p.s


    職場の桐仲間が Thin_INF_Framework と INF_Framework を活用し始めました。
    感想を聞くと、便利だと言っていました。


    しかも、私は何も言っていないのに、INF_Framework を使いだして、
    &hwindow から 別フォーム に手続き名を送信したいと言ってきました。


    既にフォームを自作しているもので手続き名を送信したかったみたいなので、ダウンロード掲示板の Thin_INF_Framework プロトタイプを組み込めば 送信可能だよ と教えて、組み込み方と使い方を軽くレクチャーしました。


    30分位して、送信出来ましたと言ってきて、この Framework は凄いと感動していました(^^♪


    イベント処理から一括処理に入っていくと、自由にプログラムが書けるので
    出来るかどうかは別として手続き名を送信したいと発想出来やすいのかもしれません(^^ゞ


引用返信 [メール受信/OFF]
■604 / ResNo.2)  Re[2]: Thin_INF_Framework for 桐10s/ 桐sSL / 桐sLT
□投稿者/ ONnoji -(2024/12/05(Thu) 19:30:04)
    2024/12/07(Sat) 22:21:29 編集(投稿者)
    2024/12/05(Thu) 23:21:40 編集(投稿者)

    ジェダイの桐さん

    > イベント処理のランチャー・シーカー・メッセージセンダーThin_INF_Framework
    > の正式リリース楽しみにしていました!

    拙作:Thin_INF_Framework をダウンロードいただきありがとうございます。

    また、Thin_INF_Framework の紹介文も寄稿していただきまして改めて感謝申し上げます。

    > 私は現状 INF_Framework 若しくは Thin_INF_Framework でフォーム作成しています。
    > 今でも、メッセージのやり取りは、トレース出力をかなり使用し、どのプログラムにいるか流れを詳細に分かる様にしないと難しい部分があります。
    > が、しかし、やっぱり失敗しながらでも 流れと変数の値 を確実に確認しながら使用していると、当初より流れがイメージ出来る様になってきたんですよ(^^ゞ

    Thin_INF_Framework に同梱した

     INF_Framework.cmx … Rev.272
     IPS_Framework.cmx … Rev.272

    は、[コマンド]コマンドで実行する箇所に手を入れて、桐本体の替わりにフレームワーク側からエラーを表示するように手を入れました。

    これは、メッセージセンダーとタイマー実行とダブルクリックとVKです。

     ** Rev.272 2024.11.02 OnErrorHDLCOMmReceiveMacroEval 追加
     ** Rev.272 2024.11.02 OnErrorINFmMacroEval      追加
     ** Rev.272 2024.11.02 OnErrorINFprcDoubleClickEval  追加
     ** Rev.272 2024.11.23 OnErrorVKprcEventKeyEval    追加

    なお、HDLVAR は複雑でテストが間に合わなかったので従来のままです。

    この新しいライブラリファイルを、既存の Rev.265 の INF_Framework.cmx / IPS_Framework.cmx に上書きしてお使いください。

    > 不思議な物で、流れを意識しだす事で気付いた事があります。
    > 引数を使って、値を別モジュールに送る事で、モジュールの中身を抽象的に書けるなと。
    > ほんの少しですが、構造化プログラムの考え方が分かって来たような気がします。

    プロシージャ(手続き)の中に、具体的な名称を書き過ぎると、柔軟性が失われますね。

    だから、抽象的に書いて引数で値を渡せば柔軟性が得られます。

    でも、引数が多すぎると判り易さを損なうようになりますので、バランスを考えてほどほどにした方が良いですよ。

    それでも、プログレスバーでタイマーによって分割実行するような場合には、引数を多用した方が良いと思います。

     (例)

     手続き実行 prcReform3( &PRGmContinue, &PRGmRecordUnit, &mTargetFileExtension, &mProcedureName, &mProcedureNameLast, &mObjectName, &mObjectNameLast, \
      &mProcedureType, &mProcedureTypeLast, &mSectionID, &mSectionIDLast, &mEventID, &mEventIDLast, \
      &mNestNum, &mRecordNum, &mProcedureRec, &mIsYenSignNow, &mIsYenSignLast, &mLogicalStructureString, &mLevelString, \
      &mTargetFileName, &mIndentTopNum, &mIndentNum, &mIndentCaseCondNum, &mIndentCaseLineNum, &mIndentContinueNum, &mReformDate, &mIndentCommandLineNum, &mCommandName, &mTargetFileLastUpdate )

    ↑上の例は、極端な例ですが・・・(^^ゞ

    > 以前、ONnojiさんが 1つのピタゴラスイッチを押す事で、ドミノ倒しの様に次々にピタゴラ装置が動いていく。
    > この様なニュアンスの事を教えてくれました。
    > メッセージの送受信が可能になった事で、ピタゴラ装置 ドミノ倒し の意味は理解出来ました。

    ピタゴラ装置では、[ビー玉が坂道を転がって時間を稼ぐ]的な遅延動作がありますね。

    [タイマー]イベントはまさにこれに該当するというわけです。

    なお、拙作フレームワークを使えば、面倒な[タイマー]イベントを使うプログラムを自作する必要はなくて、

    既に用意されている手続きに引数を渡すだけで簡単に出来てしまいます。

    そうです!、すでに車輪は発明されているのですから、その車輪を使えば良いだけなのです。アハハハha

    フレームワークの恩恵はここにありますね。(^^ok

    > p.s
    > 職場の桐仲間が Thin_INF_Framework と INF_Framework を活用し始めました。
    > 感想を聞くと、便利だと言っていました。
    > しかも、私は何も言っていないのに、INF_Framework を使いだして、
    > &hwindow から 別フォーム に手続き名を送信したいと言ってきました。
    > 既にフォームを自作しているもので手続き名を送信したかったみたいなので、
    > ダウンロード掲示板の Thin_INF_Framework プロトタイプを組み込めば 送信可能だよ と教えて、組み込み方と使い方を軽くレクチャーしました。
    > 30分位して、送信出来ましたと言ってきて、この Framework は凄いと感動していました(^^♪
    > イベント処理から一括処理に入っていくと、自由にプログラムが書けるので
    > 出来るかどうかは別として手続き名を送信したいと発想出来やすいのかもしれません(^^ゞ

    Thin_INF_Framework をフォームに組み込めば、ランチャーとシーカーと送信器と受信器がセットされるので、

    桐のコマンド(またはメソッド)を送信できるようになります。

    「フォーム+イベント処理」では、複数のフォームの連携という所が難度が非常に高いので挫折する人が多いと思います。

    しかし、拙作を使う事が契機、つまり「ブレークスルー」となって、スイスイと複数のフォームの連携が出来るようになりますよ。

    p.s.

    なお、拙作は【多遊】さんのダウンロードコーナーでの紹介をお願いしていますが、

    【多遊】さんがご多忙なようなので、当方のwebページで先行公開しました。

    だから、フライングゲット!なんです。アハハハha

    p.p.s.

    ガントチャートの正式版といっても、ほぼほぼベータ版と同じですが

    ガントチャート 第1.0版 for 桐10s/ 桐sSL / 桐sLT
    Gantt_chart_finel_For_Kiri10sAA.zip 約910KB

    こちらも、同じく公開しています。


引用返信 [メール受信/OFF]

■記事リスト / レス記事表示 → [親記事-2]



■記事リスト / ▼下のスレッド / ▲上のスレッド
■595 / 親記事)  ダブルクリック考
□投稿者/ ONnoji -(2024/11/15(Fri) 15:00:49)
    2024/11/15(Fri) 18:04:50 編集(投稿者)


    ジェダイの桐さん

    > 確かにそうですね・・・
    > オペレーターに聞いてみたら、便利ですねと言ってはくれましたが
    > 反応は薄かったです。
    > そのオペレーターにとっては、比較式で絞込が出来ればいい訳で
    > 従来通り、下部にあるファンクションキーの様なボタンを押して絞り込みをするのかもしれません。

    > 私( ONnoji )の予感が当たりましたね。ガハハハハ。
    > このような[作る側と使う側の齟齬(くいちがい)]はよくある事なのですよ。
    > よく考えてください、[使う側]は使う事で精一杯なんですよ。
    > だから、ダブルクリックでなんて余計な操作に思えてしまって、「ふ〜ん、それが何なのサッ」となるんですよ。

    > 今回は同じ社内で、ある意味私のフォームの押し付けなので
    > 齟齬があっても良いと思うんですよ。
    > (勿論ない方がよいですけど^_^)

    ダブルクリックは、キーボードからマウスへ持ち替えなければなりませんから、嫌がる人は居ると思いますよ。
             ・・・・・・・・・・・・・・・・・・・・・・・・

    こういうところは、人それぞれなんですよね。

    せっかくキーボードだけでの操作を覚えたのに、マウス操作まで覚えるのはイヤヨイヤイヤとなるんですよ。

    でも、これは無意識に脳の中で起きる事なんですよ。
       ・・・・・・・・・・・・・・・

    誰だって快適になりたいわけです。※自分の好きなように、自分のメンタルモデルに従って・・・
    ・・・・・・・・・・・・・・・

    自動車を運転する時に、座席シートの位置を調整するでしょう。

    だからそれと同じように、誰でもアプリケーションをなるべく快適に操作したいわけですよ。

    それが、キーボードだけの一刀流か、マウスも使う二刀流かの違いですね。

    これは良い悪いの話ではなくて、ユーザインタフェースの問題なんですよ。

    さて、今回のダブルクリックはイマイチだったわけですから、

    <使う人側>の人には、「1カ月たったら感想を聞かせてください」と伝えてそのまま使っ貰ったらいかがでしょうかね。

    そして、時期が来たら感想をヒアリングして、機能を削除するか否か決めればオーケーですよ。

    とにかく、慌てない事です。

    案外と便利だと気が付く場合だってあるわけですよ。

    新しい機能というのは、<使う側>に慣れる時間が必要なんですよね。アハハハha

引用返信 [メール受信/OFF]

▽[全レス3件(ResNo.1-3 表示)]
■597 / ResNo.1)  Re[1]: ダブルクリック考
□投稿者/ ONnoji -(2024/11/15(Fri) 15:50:47)
    2024/11/16(Sat) 11:08:19 編集(投稿者)

    ジェダイの桐さん

    > でも、システム開発会社(受注者)と システム発注者 の関係性だったら
    > 死活問題ですよね…

    そうならないように、事前の調整を丁寧にしないといけませんよね。

    まず、発注側と受注側がよく話し合う事ですよ。

    なんだ!当たり前じゃん!!ですが、これが実際はなかなか出来ないんですよ。

    一番問題になるのは、発注側が丸投げするケースですね。

    ろくに打ち合わせもしないで、経営者が知り合いの業者へ丸投げするなんていうケースがあるんですよ。

    ワンマン経営の会社だと、実際に使う現場の意見を聞かないで、経営者だけで勝手に決めちゃう。

    これは最悪で、納品されたソフトウェアを巡って現場では不満が溜まっていくワケです。

    ※実際にそういう現場に転職した経験があるので、実感としてありますよ。最悪。(T_T)

    > プログラマーが、依頼者にヒアリングして齟齬があった場合
    >  プログラマーのヒアリング不足
    >  依頼者が具体的に伝えきれていない
    > どちらの問題が大きいんですかね??
    > ケースバイケースなんでしょうけど、これは、プログラマーの経験値で回避出来る事が
    > 多いんでしょうかね。

    プログラマーという言葉が指すものが曖昧なので、開発者と言い換えます。

    コンピュータという物は、ソフトウェアを取り替えることで、何にでも対応できる万能な柔らかな機械なわけです。

    だから、コンピュータの適用範囲というのは、家電製品から人工衛星までといった具合に無限なんですよ。

    そんなわけで、すべてに精通した開発者なんてこの世に存在しないんですよ。

    だから、ある限られた分野に精通しているだけなんですよ。

    また、誰だって最初は初心者なのですから、最初からある分野のソフトウェアのエキスパートなんていう人も居ないんですよ。

    これって当たり前ですよね。アハハハha

    ただ一つ言えることは、開発者の経験が少なくても豊富でも、

    開発者は「よいソフトウェアを創ろう」とするわけですよ。

    これは、外注でも内製でも同じなんです。

    だから、<作る側>と<使う側>がよく話し合う事が必要なのです。

    でもね、<使う側>が話し合いに応じないケースもあるんですよね。

    つまり、「お任せするので、後はよろしく」という態度ですね。

    これはよくあるんですよ。

    「私はPCに詳しくないから全部お任せ」というやつですね。

    でも、これはヤバイのですよ。

    後になって、ここを直してくれぇ〜と文句を言うか泣きつかれるんですよね。

    だから、作る時に最初から言え!!と思っちゃいますよね。

    なので、「私はPCに詳しくないから全部お任せ」という連中と組む場合には、

    彼らの仕事内容をよく観察して、自分の考えをまとめていくしか方法が無いんですよ。

    困ったことに、何を聞いても「私はPCに詳しくないから全部お任せ」という連中は必ず居るんですよ。ガハハハ。

    だから、よく観察して、方針を決めて、ソフトウェアを開発するしかないですね。残念ながら・・・

    > きっと依頼者は潜在的にこう言う事を求めているのでは??
    > と、ニーズを引き出していくんですかね^_^
    > とは、言っても、いくら熟練のプログラマーでも依頼者の業務に精通している
    > 訳じゃないから、依頼者もやりたい事を具体的に伝えないといけないですよね。

    その通りです。

    よく観察することですよ。

    >> 誰のためのデザイン? 増補・改訂版 ―認知科学者のデザイン原論
    > Amazonのレビューを読んでみました。
    > 非常に興味深かったので、早速ポチりました^_^

    もちろん、この本を知らない人はたくさん居ますが、ソフトウェアの開発者・デザイナでこの本の名前を聞いたことが無い人は少ないでしょう。

    それくらい、有名な本ですよ。

    この本は、コンピュータの本というよりも、認知心理学の本なんですよ。

    でも、PCは人間とソフトウェアの対話で操作するでしょう。

    だから、人間側の特性も知っておかなければならないんですよ。

    つまり、[PCの特性]と[人間の特性]の両面の知識が求められるんですよ。

    開発者は「よいソフトウェアを創ろう」とするわけですから、これは必要なことですね。

    以前、

     ■506 / 親階層) INF_Framework の話をしよう □投稿者/ ONnoji -(2024/09/13(Fri) 14:29:26)

    で、ベン・シュナイダーマンの「ユーザーインターフェイスデザインの8の黄金律」のことを紹介しました。

    これをアプリ開発のガイドラインとしてください。

    最初は判らなくても、今回の「誰のためのデザイン?」を読めばよく理解できると思いますよ。


引用返信 [メール受信/OFF]
■600 / ResNo.2)  Re[2]: ダブルクリック考
□投稿者/ ONnoji -(2024/11/16(Sat) 16:14:45)
    2024/11/16(Sat) 16:47:00 編集(投稿者)

    > ただ一つ言えることは、開発者の経験が少なくても豊富でも、
    > 開発者は「よいソフトウェアを創ろう」とするわけですよ。
    > これは、外注でも内製でも同じなんです。

    これは、無料のソフトウェアでも、有料のソフトウェアでも同じです。

    ところがソフトウェアに虫見付けて、ヒステリーみたいに騒ぐ人がいるんですよね。

    虫が居ることは避けるべきことですが、虫は取り尽くせないんですよ。

    もちろん、数十行やそこらのプログラムならば、虫なんて居ないのが普通です。

    しかし、大規模なプログラムの場合には、どんなに頑張っても、虫は取り尽くせないです。

    これはテストをすり抜ける、つまりテストされずに見過ごされた虫が必ず居るということです。※潜在バグと言います

    だから、リリースから長い時間が経ったプログラムというのは、いわゆる枯れた状態で虫が少なくなっているんですよ。

    もちろん、誰も使わないプログラムならば、時間が経過しても虫は見つからないままですけれどね。

    ちなみに、必ず虫が居ると思うと気持ちが悪いですが、虫にもいろいろあって、避けて通れる事も多いです。

    また、常識的な使い方をしている場合には、まず虫に出会わないのが普通です。

    「この宇宙に地球以外の生命体が存在するか?」という問いに対して、可能性はゼロでは無いと考えられる人ならば、

    「ソフトウェアに虫がいるか?」の答えもおのずと判るでしょう。アハハハha

引用返信 [メール受信/OFF]
■601 / ResNo.3)  Re[3]: ダブルクリック考
□投稿者/ ONnoji -(2024/11/17(Sun) 17:05:01)
    2024/11/17(Sun) 17:14:02 編集(投稿者)

    以下に再掲載します。

     ■名称:ダブルクリックでコマンドを実行する

      手続き名(引数):INFprcDoubleClickEval( &this, &macro )

      値渡し引数:

       文字列/ &this … [マウス左クリック]イベントが発生したオブジェクトのオブジェクト名
       文字列/ &macro … 桐で実行可能なコマンド、またはメソッドを代入する

      使い方( usage ): 

       ※この手続きは、必ず[マウス左クリック]イベントハンドラから呼び出します。

       手続き定義開始 objectName::マウス左クリック(長整数 &マウス位置[2],長整数 &明細番号,長整数 &フラグ,参照 長整数 &処理中止)
        変数宣言 自動,文字列{ &macro }
        変数宣言 自動,文字列{ &SP = #jis( #hex("20") ) } /* 空白文字  */
        変数宣言 自動,文字列{ &WQ = #jis( #hex("22") ) } /* 二重引用符 */

        ** ダブルクリックの間隔:時間型変数:&EZWmIntervalDoubleClickDefault
        ** &EZWmIntervalDoubleClickDefault = i"0時間 0分 0.8秒" /* INF_Framework のデフォルト値 */
        &EZWmIntervalDoubleClickDefault = i"0時間 0分 1秒"    /* 適宜調整してください     */

        &macro = "確認" + &SP + &WQ + "こんにちは" + &WQ
        手続き実行 INFprcDoubleClickEval( &this, &macro )

       手続き定義終了


      (重要)

       編集可能なテキストボックスでは、ダブルクリックは出来ません。
       なぜならば、最初のクリックで、テキストボックスにキャレットが現れて、エディタに進入してしまうからです。
       エディタに進入した後には、[マウス左クリック]イベントが発生しませんので、ダブルクリックは検出できなくなります。

    ですが、

    ダブルクリックの間隔:時間型変数:&EZWmIntervalDoubleClickDefault は、既に INF_Framework の[名札 メイン]ユニットで、

    デフォルト値:i"0時間 0分 0.8秒" をセットしていますので、

    各[マウス左クリック]イベントハンドラの中に記述する必要はありません。

    こちら↓

       手続き定義開始 objectName::マウス左クリック(長整数 &マウス位置[2],長整数 &明細番号,長整数 &フラグ,参照 長整数 &処理中止)
        変数宣言 自動,文字列{ &macro }
        変数宣言 自動,文字列{ &SP = #jis( #hex("20") ) } /* 空白文字  */
        変数宣言 自動,文字列{ &WQ = #jis( #hex("22") ) } /* 二重引用符 */

        &macro = "確認" + &SP + &WQ + "こんにちは" + &WQ
        手続き実行 INFprcDoubleClickEval( &this, &macro )

       手続き定義終了

    もしも、i"0時間 0分 0.8秒" ⇒ i"0時間 0分 1秒" のように変更するのであれば、

    [開始時実行コマンド]ボタンの[機能名:手続き実行]で呼び出す、cmdStartupClick( )等に

       手続き定義開始 cmdStartupClick( )

        ** ダブルクリックの間隔:時間型変数:&EZWmIntervalDoubleClickDefault
        ** &EZWmIntervalDoubleClickDefault = i"0時間 0分 0.8秒" /* INF_Framework のデフォルト値 */
        &EZWmIntervalDoubleClickDefault = i"0時間 0分 1秒"    /* 適宜調整してください     */

       手続き定義終了

    とします。

    ダブルクリックが複数のオブジェクトにセットされている場合には、この方が個別に指定するよりも便利ですよ。

引用返信 [メール受信/OFF]

■記事リスト / レス記事表示 → [親記事-3]



■記事リスト / ▼下のスレッド / ▲上のスレッド
■534 / 親記事)  Thin_INF_Framework ベータ2のご案内
□投稿者/ ONnoji -(2024/10/18(Fri) 12:05:58)
    2024/10/18(Fri) 12:25:27 編集(投稿者)

    2Thin_INF_Framework ベータ2のご案内

    zip のその1(1729220758.zip/167KB)を解凍すると以下のファイルがあります。

    1st_Read_Me_お読みください_Thin_INF_Framework.txt
    1st_Thin_INF_Framework_HDLCOM_サンプルについて.txt
    1st_Thin_INF_Framework_HDLLNC_サンプルについて.txt
    1st_Thin_INF_Framework_組み込みガイド.txt
    NO_FLD_EZW.kex
    NO_FLD_EZW.tbx
    NO_FLD_EZW.wfx
    NO_FLD_EZW_Launcher.kex
    NO_FLD_EZW_Launcher.wfx
    NO_FLD_EZW_Plus.kex
    NO_FLD_EZW_Plus.tbx
    NO_FLD_EZW_Plus.wfx
    NO_FLD_EZW_Receiver.kex ─┐
    NO_FLD_EZW_Receiver.tbx  │  容量オーバーのために別ファイルです
    NO_FLD_EZW_Receiver.wfx  ├─  zipのその2(1729220951.zip/62KB)
    NO_FLD_EZW_Sender.kex   │  を解凍してください。
    NO_FLD_EZW_Sender.wfx ──┘
    transaction_A.kex
    transaction_A.tbx
    transaction_A.wfx
    transaction_B.kex
    transaction_B.tbx
    transaction_B.wfx
    ユニットINF_3-3MkII_INFprcStartup_NO_FLD_EZW.txt
    ユニットINF_3-3MkII_名札メイン.txt



引用返信 [メール受信/OFF]

▽[全レス58件(ResNo.54-58 表示)]
■591 / ResNo.54)  Re[5]: Thin_INF_Framework ベータ2のご案内
□投稿者/ ONnoji -(2024/11/13(Wed) 11:49:16)
    ジェタイの桐さん

    > 色々考えた末、手続き実行 INFprcDoubleClickEvalを
    > 絞り込み(比較式)で実装してみました。
    > 実装したテキストボックスは編集しないテキストボックスです。
    > 生産日の期間絞り込みをする為に、オペレーターはフォーム下部にある
    > 桐が用意しているのファンクションキーの様なボタンから
    > 絞り込みを行っていました。
    >
    > だったら、絞り込み(比較式)を行うコマンドボタンをワークスペースか
    > ヘッダ部に作成して
    > &macro = “メソッド呼び出し @cmd絞り込み.実行()”
    > としてプログラムを動かせば、オペレーターにとって多少の効率化になるかな?
    > と思いました。
    > オペレーターの感想は明日聞いてみます!

    作る側は面白いかもしれませんが、ダブルクリックは思ったほどよりも必要な機能ではありませんよ。

    また、気が付きにくいので、ヒントテキストを表示するようにした方がいいですよ。

    作る側が良かれと思っても、使う側がピンと来ない事もありますよ。

    その場合には、手続きは他で使えるかもしれないので残しておいて動作しないようにした方がいいですよ。

    使う側にも色々ありますから、ジェダイの桐さんと友好的な人もあれば、非友好的な人もありますよ。

    だから、ウケなくてもあまり気にしない事ですよ。

    > 手続き実行 INFprcDoubleClickEval の使い道ですが、
    > 使い方によっては、更にプログラムの幅が広がる様な気がしました。

    INFprcDoubleClickEval の Eval というのは evaluation(評価)の意です。

    案外とEval を"イーバル"と発音する人も多いと思いますよ。

    p.s.

    少し前に投稿した、「銀の弾丸など無い」はお読みになりましたか??

    プログラムの規模が大きくなればなるほど、複雑さは増すものですよ。

    それは、本質的な問題なので防げないということを覚えていてください。


引用返信 [メール受信/OFF]
■592 / ResNo.55)  Re[6]: Thin_INF_Framework ベータ2のご案内
□投稿者/ ジェダイの桐 -(2024/11/14(Thu) 09:31:14)
    ONnojiさん


    おはようございます!


    > また、気が付きにくいので、ヒントテキストを表示するようにした方がいいですよ。


    そういう発想がありませんでした。
    アドバイスありがとうございますm(__)m


    > 作る側は面白いかもしれませんが、ダブルクリックは思ったほどよりも必要な機能ではありませんよ。
    > 作る側が良かれと思っても、使う側がピンと来ない事もありますよ。


    確かにそうですね・・・
    オペレーターに聞いてみたら、便利ですねと言ってはくれましたが
    反応は薄かったです。
    そのオペレーターにとっては、比較式で絞込が出来ればいい訳で
    従来通り、下部にあるファンクションキーの様なボタンを押して絞り込みをするのかもしれません。


    > p.s.
    > 少し前に投稿した、「銀の弾丸など無い」はお読みになりましたか??
    > プログラムの規模が大きくなればなるほど、複雑さは増すものですよ。
    > それは、本質的な問題なので防げないということを覚えていてください。


    読みました。かなり深い話だと思いました。
    あのWikipediaを読んで

     1、よいデザイナーは偉大なデザインを生み出せない。
       偉大なデザイナーのみ偉大なデザインを生み出せる。

     2、銀の弾などない再発射の時点で、1986年に想定した予想を下回っていた。
       なら、2024年時点では 1986年想定は 超えているのかな??

    上記2点 印象に残りました。


    偶有的な複雑性を除いた、本質的な複雑性の解決方法は
    プログラマー自身がレベルアップするしかないんでしょうね(^^ゞ


引用返信 [メール受信/OFF]
■593 / ResNo.56)  Re[7]: Thin_INF_Framework ベータ2のご案内
□投稿者/ ONnoji -(2024/11/14(Thu) 11:58:34)
    2024/11/14(Thu) 12:17:07 編集(投稿者)

    ジェダイの桐さん

    >>作る側は面白いかもしれませんが、ダブルクリックは思ったほどよりも必要な機能ではありませんよ。
    >>作る側が良かれと思っても、使う側がピンと来ない事もありますよ。
    > 確かにそうですね・・・
    > オペレーターに聞いてみたら、便利ですねと言ってはくれましたが
    > 反応は薄かったです。
    > そのオペレーターにとっては、比較式で絞込が出来ればいい訳で
    > 従来通り、下部にあるファンクションキーの様なボタンを押して絞り込みをするのかもしれません。

    私( ONnoji )の予感が当たりましたね。ガハハハハ。

    このような[作る側と使う側の齟齬(くいちがい)]はよくある事なのですよ。

    よく考えてください、[使う側]は使う事で精一杯なんですよ。
              ・・・・・・・・・・・・・

    だから、ダブルクリックでなんて余計な操作に思えてしまって、「ふ〜ん、それが何なのサッ」となるんですよ。

    これは[使う側]に軍配が上がっちゃいますね。

    こういう事はよく起きますから、これに懲りずに頑張ってください。アハハハハha

    大事な事を申し上げますが・・・

    [作る側]つまりジェダイの桐さんが、今回作っているアプリケーションに対する自分のイメージ、

    正確にはモデルで、もっと正確に言えばメンタルモデルですが、

    これは、[使う側]と一致していないことの方が多いのですよ。

    「エェ〜〜〜〜そんな馬鹿な!」と思ったでしょ。

    でも、これはホントです。

    ただし、それは個々の人の心の中にあって見えないので気が付きにくいんですよ。

    これね
      ↓
     メンタルモデル 出典: フリー百科事典『ウィキペディア(Wikipedia)』
     メンタルモデル(英: mental model)とは、頭の中にある「ああなったらこうなる」といった「行動のイメージ」を表現したものである。

    また、習慣というのも、頭の中にある「ああなったらこうなる」を基準にしているわけですよ。

    だから、[作る側]と[使う側]が一致しているわけでは無いのです。

    早い話が、PCに詳しい人と、PCに疎い人では、PC対する感性が異なっているということですよ。

    以前ですが、プログラミングは心理学とか、ユーザインターフェースの知識不足と書いたことがあります。

    非常に有名な書籍があるので、会社の経費で買って貰って読んでみてください。

     誰のためのデザイン? 増補・改訂版 ―認知科学者のデザイン原論
     出版社 :新曜社; 増補・改訂版 (2015/4/23)
     発売日 :2015/4/23
     言語  :日本語
     単行本 :520ページ
     ISBN-10 :4092534647
     ISBN-13 :978-4788514348

    こういう本は売れないからバカ高いのですよ。会社に本代を払わせた方がいいですよ。アハハハ

    >>p.s.
    >>少し前に投稿した、「銀の弾丸など無い」はお読みになりましたか??
    >>プログラムの規模が大きくなればなるほど、複雑さは増すものですよ。
    >>それは、本質的な問題なので防げないということを覚えていてください。
    > 読みました。かなり深い話だと思いました。
    > あのWikipediaを読んで
    >  1、よいデザイナーは偉大なデザインを生み出せない。
    >    偉大なデザイナーのみ偉大なデザインを生み出せる。

    アラン・ケイとかね、天才でないとイノベーションは起きないのですよ。

    >  2、銀の弾などない再発射の時点で、1986年に想定した予想を下回っていた。
    >    なら、2024年時点では 1986年想定は 超えているのかな??
    >

    少し前に、無料版のChatGPT で、Windows PowerShell とエクセルのプログラミング方法を尋ねたことがあります。

    Windows PowerShell に関しては、まあまあの成果物が得られましたが、

    エクセルに関しては、小学生以下の成果物でした。

    AIって学習結果を繋ぎ合わせているんですよね。

    でも、学習に使った資料は人間が作ったものでしょう。

    なんか、ニワトリが先かタマゴが先かみたいになっちゃって・・・アハハハ

    > 偶有的な複雑性を除いた、本質的な複雑性の解決方法は
    > プログラマー自身がレベルアップするしかないんでしょうね(^^ゞ

    誰でも、F1レーサーや宇宙飛行士に成れないように、

    まずは、プログラマーとしての適性があるかがベースになりますが、 ※誰にでも「向き・不向き、得意・不得意」があるのが普通です

    後は、シンプルな考え方が出来ることだろうと思いますよ。

    知識に関しては、社内で桐のアプリ開発をしているのであれば、専門知識のコンピュータサイエンス(コンピュータ科学)のお勉強は必要無いですよ。

    だから、ITパスポート程度のPC環境の常識を知っていれば十分ですよ。

引用返信 [メール受信/OFF]
■594 / ResNo.57)  Re[8]: Thin_INF_Framework ベータ2のご案内
□投稿者/ ジェダイの桐 -(2024/11/14(Thu) 20:01:19)
    ONnojiさん


    こんばんは!


    > このような[作る側と使う側の齟齬(くいちがい)]はよくある事なのですよ。
    > よく考えてください、[使う側]は使う事で精一杯なんですよ。
    >           ・・・・・・・・・・・・・


    今回は同じ社内で、ある意味私のフォームの押し付けなので
    齟齬があっても良いと思うんですよ。
    (勿論ない方がよいですけど^_^)


    でも、システム開発会社(受注者)と システム発注者 の関係性だったら
    死活問題ですよね…


    プログラマーが、依頼者にヒアリングして齟齬があった場合

     プログラマーのヒアリング不足
     依頼者が具体的に伝えきれていない

    どちらの問題が大きいんですかね??
    ケースバイケースなんでしょうけど、これは、プログラマーの経験値で回避出来る事が
    多いんでしょうかね。


    きっと依頼者は潜在的にこう言う事を求めているのでは??
    と、ニーズを引き出していくんですかね^_^


    とは、言っても、いくら熟練のプログラマーでも依頼者の業務に精通している
    訳じゃないから、依頼者もやりたい事を具体的に伝えないといけないですよね。


    >  誰のためのデザイン? 増補・改訂版 ―認知科学者のデザイン原論


    Amazonのレビューを読んでみました。
    非常に興味深かったので、早速ポチりました^_^

    プログラム以前に、レビューから読み取れたのは、人間心理って面白いなって思いました。
    明日届くので読み込みます!

    面白そうな書籍紹介ありがとうございますm(_ _)m

引用返信 [メール受信/OFF]
■596 / ResNo.58)  Re[9]: Thin_INF_Framework ベータ2のご案内
□投稿者/ ONnoji -(2024/11/15(Fri) 15:02:22)
    ジェダイの桐さん

    脱線気味になったので、別のツリーで続けます。

引用返信 [メール受信/OFF]

■記事リスト / レス記事表示 → [親記事-9] [10-19] [20-29] [30-39] [40-49] [50-58]



■記事リスト / ▼下のスレッド / ▲上のスレッド
■506 / 親記事)  INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/09/13(Fri) 14:29:26)
    2024/09/13(Fri) 17:36:23 編集(投稿者)

    INF_Framework の話をしよう

    ベン・シュナイダーマンの著書の

     Designing the User Interface: Strategies for Effective Human - Computer Interaction,
     ※ユーザー インターフェイスの設計: 効果的な人間とコンピューターの対話のための戦略

     Shneiderman, Ben. Designing the User Interface: Strategies for Effective Human–Computer Interaction,
     1st edition. Addison-Wesley, 1986;
     2nd ed. 1992;
     3rd ed. 1998;
     4th ed. 2005;
     5th ed. 2010;
     6th ed. 2016

    ↑は、ユーザインタフェースに関するベストセラーです。

    1986年の初版から、コンピュータの日進月歩に合わせて、第6版まで改訂され続けたスゴイ書籍です。

    日本での翻訳は、

    ユーザー・インタフェースの設計  : 使いやすい対話型システムへの指針 日経BP社 1987
    ユーザー・インタフェースの設計  : やさしい対話型システムへの指針  日経BP社 1993

    ↑のようにわずかに初版と第2版のみです。

    しかも、このように古くて、古書ではバカ高い値段が付いています。

    ユーザインタフェースに関する書籍って日本では売れないんでしょうね。これっきりで終わっています。

    さて、ベン・シュナイダーマンのこの書籍の中で紹介されている

    ・対話デザインの 8 つの黄金律( Eight Golden Rules of Dialogue Design )

    ・ユーザーインターフェイスデザインの8つの黄金律( The 8 golden rules of user interface design )

    は、Dialogue Design が、user interface design に置き換わっただけで同じ内容です。

    日本でもwebで紹介されていますが、原文の雰囲気に忠実に訳したものは少ないように思います。

    そこで、私( ONnoji )が、この「ユーザーインターフェイスデザインの8つの黄金律」を

    拙作:INF_Framework と絡めてご紹介してゆこうと思います。

    まずは、

    1.Strive for consistency です。

    訳すと「一貫性を保つよう努める」ですね。

      1.一貫性をもたせる
       この原則はもっとも侵害されやすいが,修正したり避けるのも簡単である。
      似たような状況では,一貫した一連の操作が要求され,プロンプト・メッセージやメニュー,ヘルプ画面では同じ用語を使い,
      システム全体のコマンド形式は同じでなければならない。
      パスワードは表示されない,DELETEコマンドは省略を許さないなどの例外はもちろんあるが,最小限にすべきである。
      【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針|ベン・シュナイダーマン 著|日経BP社 1987|ISBN4-8222-7053-X

    桐的に思いっきり意訳すると次↓のようになります。

    1.一貫性をもたせる( Strive for consistency )

      この原則は守られ難いが、避けることは簡単です。
     よく似た状況では、メッセージボックスのメッセージや、フォーム上のメニューは同じ用語を使って、
     アプリケーション全体の操作方法は、同じでなければならない。

    と、上のように意訳しました。(^^ゞ

    <続く>

引用返信 [メール受信/OFF]

▽[全レス19件(ResNo.15-19 表示)]
■529 / ResNo.15)  Re[11]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/10/01(Tue) 15:22:08)
    2024/10/01(Tue) 16:58:30 編集(投稿者)

    7番めの黄金律は、

    7.Support internal locus of control( Keep the User in Control ) です。

    訳すと「主体的な制御権を与える」ですね。

     7.主体的な制御権を与える

      経験の豊富な操作者は,自分がシステムを制御し,システムは単に彼らの操作に応答しているという感覚を強く望んでいる。
     ユーザーを驚かすようなシステムの反応やうんざりするほどの量のデータ入力,
     あるいは欲しい情報を得ることが不可能または困難であったり,期待した応答ができないなどはすべてユーザーを不安にしたり不機嫌にさせる原因である。
     Gaines(1981)はこの原理を,「不条理を避ける」という彼の原則と,ユーザーを応答者にするのでなく主導権を与えるという提案で表現している。
    【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針|ベン・シュナイダーマン 著|日経BP社 1987|ISBN4-8222-7053-X

    桐的に意訳すると次↓のようになります。

     7.主体的な制御権を与える( Support internal locus of control / Keep the User in Control )

      経験豊富なPCユーザは、自分がシステムを制御し、システムは単に彼らの操作に応答しているという感覚を強く望んでいる。
     ユーザーを驚かすようなシステムの反応やうんざりするほどの量のデータ入力,
     あるいは欲しい情報を得ることが不可能または困難であったり、期待した応答ができないなどはすべてユーザーを不安にしたり不機嫌にさせる原因である。
     Gaines(1981)はこの原理を,「不条理を避ける」という彼の原則と、ユーザーを応答者にするのでなく主導権を与えるという提案で表現している。

    例えば、複数のテキストボックスに文字を入力していくフォームの場合、

    ひとつのテキストボックスの入力が確定する度にエラーチェックをしても良いが、

    エラーしたテキストボックスの文字色を赤色にする程度にして、

    その都度メッセージボックスでエラーを通知するのは避けるべきです。

    何故ならば、キーをミスタッチするのは普通の事ですから。

    エラーのチェックは、すべての入力が終わってから、まとめてチェックをするのが望ましいです。

    もしも、エラーが見つかったならば、その時にメッセージボックスを表示するだけで十分です。

引用返信 [メール受信/OFF]
■530 / ResNo.16)  Re[12]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/10/01(Tue) 17:28:15)
    8番めの黄金律は、

    8.Reduce Short-Term Memory Load です。

    訳すと「短期記憶領域の負担を少なくする」ですね。

    8.短期記憶領域の負担を少なくする

      人間の短期記憶領域には限度( 7土2のかたまり)があるので,
     表示は簡潔にし,何べージにもわたるような表示は統合しウインドウの移動を少なくし,
     コードや記号,一連の操作を学習するために十分な時間を用意する必要がある。
     必要に応じて,コマンドの構文形式,省略形,コードなどの情報をオンライン検索できるとよい。
    【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針|ベン・シュナイダーマン 著|日経BP社 1987|ISBN4-8222-7053-X


    桐的に意訳すると次↓のようになります。


    8.短期記憶領域の負担を少なくする( Reduce Short-Term Memory Load )

      人間の短期記憶領域には限度( 7土2のかたまり)があるので、
     表示は簡潔にし、何べージにもわたるような表示は統合しウインドウの移動を少なくし、
     コードや記号、一連の操作を学習するために十分な時間を用意する必要がある。

     ※「必要に応じて」以降の文言はコマンド入力型のアプリケーション対象にしているので翻案しません。


    人間の短期記憶領域という言葉を聞いたことが無い人もあるかと思います。

    例えば、一度に長い電話番号は覚えにくいけれど、いくつかの数字に区切ると覚えやすい。

    この時の単位が、[7土2のかたまり]だという主張です。

    この[かたまり]のことを[チャンク]と言います。

    [チャンク]は7土2ではなく、4土2だという最近の研究結果もあるようですが、

    人によって、また体調によってn土2のnは変わるでしょう。

    いずれにしても、この人間の短期記憶の[チャンク]を超えると短期記憶の負担が多くなります。

    つまり、疲れます。(^^ゞ

    なので、「表示は簡潔にし、何べージにもわたるような表示は統合しウインドウの移動を少なくし」となります。

    迷子になるアプリケーションやwebページは、この黄金律を守っていない事が多いですね。


引用返信 [メール受信/OFF]
■531 / ResNo.17)  Re[13]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/10/01(Tue) 17:40:41)
    2024/10/01(Tue) 17:51:51 編集(投稿者)

    以上、ベン・シュナイダーマンの

    ・対話デザインの 8 つの黄金律( Eight Golden Rules of Dialogue Design )

    ・ユーザーインターフェイスデザインの8つの黄金律( The 8 golden rules of user interface design )

    をご紹介しました。

    この8つの黄金律は、非常に有名なものなので是非一読をお勧めいたします。

    以下は ONnoji が多少アレンジした8つの黄金律です。

     1.一貫性をもたせる( Strive for consistency )

      この原則は守られ難いが、避けることは簡単です。
     よく似た状況では、メッセージボックスのメッセージや、フォーム上のメニューは同じ用語を使って、
     アプリケーション全体の操作方法は、同じでなければならない。

     2.頻繁に使うユーザーには近道を用意する( Enable frequent users to use shortcuts )

      使用頻度が高くなると、ユーザはなるべく少ない手順でそうしたいと感じる。
     初級者よりも上級者の方が、アクセスキーや特殊キー、マクロ機能を歓迎します。
     頻繁に使用するユーザには、応答時間の短縮と表示速度の向上が魅力的である。

     3.有益なフィードバックを提供する( Offer informative feedback )

      すべての操作に対して、アプリケーションは何らかのフィードバックを返すべきです。
     副次的な操作に対するメッセージは簡潔にして、重大な操作へのメッセージは情報量を多くするべきである。
     操作対象を視覚的に表現すると、ユーザは変化を常に把握できるので操作し易い。

     4.段階的な達成感を与える対話を実現する( Design dialogues to yield closure )

      作業の流れにも起承転結が必要である。
     一連の作業をやり遂げた時にオペレータにその事をを知らせるフィードバックは、
     仕事をやり遂げたという満足感、安心感を与え、不測の事態を起こす可能性を少なくするとともに、次への作業の準備を促す。

     5.エラーの処理を簡単にさせる( Offer Simple Error Handling )

      出来るだけユーザが致命的なエラーを起こさないように設計しなければならない。
     しかし、もしもエラーが起きてしまったならば、アプリケーションがその原因を見つけ出して、単純で分かり易い対処方法を提供するように心がける。

     6.逆操作を許す( Permit easy reversal of actions )

      出来る限り操作は可逆的にするべきである。
     誤った操作をしても、それを取り消せることを知っていれば不安にならないし、
     よく知らない機能でもそれを試してみる気にさせます。
     逆戻しの単位は、1回の操作やデータの入力、または一連の操作であることも考えられる。

     7.主体的な制御権を与える( Support internal locus of control / Keep the User in Control )

      経験豊富なPCユーザは、自分がシステムを制御し、システムは単に彼らの操作に応答しているという感覚を強く望んでいる。
     ユーザーを驚かすようなシステムの反応やうんざりするほどの量のデータ入力,
     あるいは欲しい情報を得ることが不可能または困難であったり、期待した応答ができないなどはすべてユーザーを不安にしたり不機嫌にさせる原因である。
     Gaines(1981)はこの原理を,「不条理を避ける」という彼の原則と、ユーザーを応答者にするのでなく主導権を与えるという提案で表現している。

     8.短期記憶領域の負担を少なくする( Reduce Short-Term Memory Load )

      人間の短期記憶領域には限度( 7土2のかたまり)があるので、
     表示は簡潔にし、何べージにもわたるような表示は統合しウインドウの移動を少なくし、
     コードや記号、一連の操作を学習するために十分な時間を用意する必要がある。

     ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

     フォームアプリケーションを作る際に、ユーザインタフェースで悩むことがあったら、

    是非ベン・シュナイダーマンの8つの黄金律を思い出してください。

    そうすれば、問題解決の糸口が必ず見つかるはずです。


引用返信 [メール受信/OFF]
■532 / ResNo.18)  Re[1]: INF_Framework の話をしよう
□投稿者/ ジェダイの桐 -(2024/10/02(Wed) 09:36:52)
    ONnojiさん


    おはようございます!


    記事全て読ませて頂きました。


    8つの黄金律解説を読んで、身の回りでは

     Amazon
     ユニクロ

    の登録画面、がこの黄金律の条件を達成しているのかな?
    と感じました。


    私自身が桐で即対応出来そうな事は

    >  1.一貫性をもたせる( Strive for consistency )

    こちらです。
    これは、作成する時に気を付ける事が出来れば達成出来そうだからです。

    2〜8は今の私の力量では、真似事 .or 対応不可 かなと感じました。


    但し、設計する上での8つの黄金律を基本概念として開発するだけでも
    今までより、使用者にとって使いやすい物が作れると思います。

引用返信 [メール受信/OFF]
■533 / ResNo.19)  Re[2]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/10/02(Wed) 11:10:00)
    ジェダイの桐さん

    > 記事全て読ませて頂きました。

    ありがとうございます。

    > 8つの黄金律解説を読んで、身の回りでは
    >  Amazon
    >  ユニクロ
    > の登録画面、がこの黄金律の条件を達成しているのかな?
    > と感じました。

    webページのデザイナーならば、ベン・シュナイダーマンの[8つの黄金律]は常識だと思いますよ。

    しかし、もはやこれは古典となっているので、敢えて[8つの黄金律]と呼ばないことも多いと思います。

    > 私自身が桐で即対応出来そうな事は
    >> 1.一貫性をもたせる( Strive for consistency )
    > こちらです。
    > これは、作成する時に気を付ける事が出来れば達成出来そうだからです。

    そうですね。

    一貫性が大事ですね。難しい事ではありませんよ。

    > 2〜8は今の私の力量では、真似事 .or 対応不可 かなと感じました。
    > 但し、設計する上での8つの黄金律を基本概念として開発するだけでも
    > 今までより、使用者にとって使いやすい物が作れると思います。

    プログラミングというと理数系と思う人が案外と多いですが、

    桐やエクセルのプログラミングは、

    純粋なコンピュータサイエンス(計算機科学)ではありませんので、

    基本制御構造を知っていれば足ります。

    そして、最も足らないのがユーザインタフェースの部分です。

    だから、「プログラミングは心理学である」と言っても言い過ぎではありませんよ。アハハハハha


引用返信 [メール受信/OFF]

■記事リスト / レス記事表示 → [親記事-9] [10-19]



■記事リスト / ▲上のスレッド
■512 / 親記事)  モードレスB で さよなら。モードレスB を閉じる
□投稿者/ ONnoji -(2024/09/18(Wed) 20:45:45)
    2024/09/19(Thu) 07:41:50 編集(投稿者)

    ジェダイの桐さん

    > スレッドを興味深く読ませて頂いています。
    > こちらの解説を読むことで、出来るかどうかは別として
    > >ウィンドウ終了コマンドでフォームを閉じる事は、有りなのかが知りたい。
    > この考え方は、「 フォーム + イベント 」 では不自然だと言う事が、より理解出来ました(^^ゞ

    考え方でありますが・・・

    以前、こういうのがありましたね。(^^ゞ

    ■491 / 9階層)  Thin_INF_Framework のご案内
    □投稿者/ ONnoji -(2024/09/10(Tue) 18:33:52)
    >> 最終的には モードレスな「フォーム+イベント処理」+モードレスな「フォーム+イベント処理」 を目指したいですが、
    >> モードレスA → こんにちは。モードレスB → モードレスB で こんにちは。モードレスB を表示
    >> モードレスB → こんにちは。モードレスA → モードレスA で こんにちは。モードレスA を表示
    >> と言う、やり取りを作る所からというイメージを抱きました。

    この視点からすると・・・、

    モードレスA → さよなら。モードレスB → モードレスB で さよなら。モードレスB を閉じる
    モードレスB → さよなら。モードレスA → モードレスA で さよなら。モードレスA を閉じる

    になりますよね。(^^ok

    どうも混乱されているようなので、頭の中を整理しましょう。(^^ゞ

    結論からすると以下のようになります。

    × [ウィンドウ終了 <ハンドル>]

    △ [メソッド呼び出し ハンドル = <ハンドル>, 戻り値 = <変数名>, <コマンドボタン>.実行()]

      ※ただし、<コマンドボタン>には[機能名:閉じる]が設定してあるとします

    〇 &sendMacro = "メソッド呼び出し ハンドル = <ハンドル>, 戻り値 = <変数名>, <コマンドボタン>.実行()"
      手続き実行 HDLCOMprcMacroSend( &hdl, &sendMacro, &done )


    理由を示して解説すると・・・

    × は、まるでダメ男です。これは一括処理の中では有効ですが、[フォーム+イベント処理]では百害あって一利なしです。

    △ は、確かに実行できます。しかし、自分自身以外のフォームとの結合度が強くなります。フォームの場合でも強い結合度は好ましくありません。
        ダイレクトにハンドルを指定してメソッドを実行するので、自分自身以外のフォームとの結合度が強くなります。    
        プログラムの流れは、複数のフォームのイベントハンドラや手続きを誘発しながら、
                  ・・・・・・・・・・・・・・・・・・・・・・・・・・・
        連続して発生するのでプログラムの流れを追うこと困難になります。つまり、デバッグし難いアプローチです。
        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    〇 は、INF_Frameworkの[HDLCOM]機能を利用しています。[HDLCOM]機能は相手のフォームの[タイマー]を経由して実行するので、
        自分自身以外のフォームとの結合度が弱くなります。
        ・・・・・・・・・・・・・・・・・・・・・・・
        プログラムの流れは自身のフォームのプログラムの流れが終わってから、
        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
        フォーム毎に別々に発生するので、プログラムの流れを追うこと簡単です。つまり、デバッグし易いアプローチです。
        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    以上のような結果に、「なりマンネン。なるんデッセ。なるチューテンネン。なりまんニャワ」。v(^^)v


    p.s.

    以前、こんなやりとりがありましたっけ。(^^ゞ

    ■501  Re[3]: Thin_INF_Framework のご案内
    □投稿者/ ジェダイの桐 -(2024/09/12(Thu) 12:21:12)
    > HDLCOMprcMacroSend について
    > フォーム間で 値の送信が出来る素晴らしい仕組みです。
    > 何故、フォーム間での 値送信 がやりたかったか思い出しました。
    > 私の シックリくる こない の全てのスタート地点が
    >  ■14365 モジュール化はフォームのレベルでも必要
    > なのです。
    > 相手側で 主 に直接影響を与えるアプローチは良くない の概念がここで生まれたのでした(^^ゞ
    > あの時は、プログラムを書くこと自体がほぼ初めてでした。
    > 下手に固定概念が着く前に上記の概念を教えて頂いた事が私にとって物凄い幸運でした(^^♪
    > それで 解決方法 &gAnswer を使ったアプローチサンプルをご提案頂きました。
    > この時に "ピタゴラスイッチ" を覚えました。
    > 同一の ○○.kex 内であれば 手続きで 値渡し 若しくは 戻り値でピタゴラスイッチが作れます。
    > 複数のフォーム間であった時、 値渡し が出来れば 相手側に直接影響を与えず、
    > ピタゴラスイッチ によって プログラム発動有無が決めれるのにな・・・
    > という思いが 値送信 に固執したのです。
    > 明らかに、幅が広がりますよね(^^♪


    ■502  Re[4]: Thin_INF_Framework のご案内
    □投稿者/ ONnoji -(2024/09/12(Thu) 14:39:00)
    > HDLCOMprcMacroSend は、&hdl で指定したフォームに桐で実行できるコマンドを送信する機能です。
    > 従って、変数を代入する静的なものではなく、コマンドまたはメソッドを実行する動的なものです。
    >
    > 例えば、変数:&hdl で指定したフォームに[確認]コマンドを送るには次のようにします。
    >
    >  変数宣言 自動,文字列{ &targetFileName }
    >  変数宣言 自動,文字列{ &sendMacro }
    >  変数宣言 自動,整数 { &found, &status, &multi, &mode }
    >  変数宣言 自動,整数 { &hdl, &done }
    >
    >  &targetFileName = #一括パス名 + "hoge.wfx"
    >  手続き実行 HDLLNCprcHdlSeek( &targetFileName, &found, &status, &multi, &mode )
    >
    >   if ( &found .and &status ) /* フォームのウィンドウが見つかった */
    >
    >    &sendMacro = "確認"
    >    &hdl = &found
    >    手続き実行 HDLCOMprcMacroSend( &hdl, &sendMacro, &done )
    >   end
    >  HDLCOMprcMacroSend は、&hdl で指定したフォームに桐で実行できるコマンドを送信する機能です。
    >                          ・・・・・・・・・・・・・・・・・・
    > 従って、変数を代入する静的なものではなく、コマンドまたはメソッドを実行する動的なものです。
    > 例えば、変数:&hdl で指定したフォームに[確認]コマンドを送るには次のようにします。


引用返信 [メール受信/OFF]

▽[全レス7件(ResNo.3-7 表示)]
■515 / ResNo.3)  Re[2]: モードレスB で さよなら。モードレスB を閉じる
□投稿者/ ジェダイの桐 -(2024/09/19(Thu) 11:22:10)
    ONnojiさん


    こんにちは!


    提示頂いた、手続きで


    >  &targetFileName = #一括パス名 + "transaction_B.wfx"

    → &targetFileName = #一括パス名 + "sample_入荷トランザクション.wfx"

    へ置き換えて、実際に cmdTest を押してみました。

    結果、 sample_入荷トランザクション.wfx は閉じました。

    サンプル提示ありがとうございましたm(__)m

    p.s.

    cmdTest を トレース出力ウィンドウ を出して実行しました。

    初めて フォーム終了イベント を見ました。
    使った事はないですが、 フォーム開始イベント で設定が出来る事は知っていました。

    同様に フォームを閉じる時も 何か設定が出来るのですね(^^♪


引用返信 [メール受信/OFF]
■516 / ResNo.4)  Re[3]: モードレスB で さよなら。モードレスB を閉じる
□投稿者/ ONnoji -(2024/09/19(Thu) 11:56:12)
    2024/09/19(Thu) 12:06:26 編集(投稿者)

    ジェダイの桐さん

    >> &targetFileName = #一括パス名 + "transaction_B.wfx"
    > → &targetFileName = #一括パス名 + "sample_入荷トランザクション.wfx"
    > へ置き換えて、実際に cmdTest を押してみました。
    > 結果、 sample_入荷トランザクション.wfx は閉じました。

    シーカーで探索して見つかったハンドルのフォームに

    実行したいコマンドボタンオブジェクトが存在するか否かを

     メソッド呼び出し ハンドル = &hdl, @フォーム.オブジェクト検査( &objectName, &isObject )

    で確かめた後に

     &sendMacro = "メソッド呼び出し @cmd閉じる.実行()"
     手続き実行 HDLCOMprcMacroSend( &hdl, &sendMacro, &done )

    でセンダーを実行しています。

    [オブジェクト検査]で石橋を叩いてから、橋が通行可能か調べています。

    このように、確実な手順を踏む習慣をお勧めします。


    > p.s.
    > cmdTest を トレース出力ウィンドウ を出して実行しました。
    > 初めて フォーム終了イベント を見ました。
    > 使った事はないですが、 フォーム開始イベント で設定が出来る事は知っていました。
    > 同様に フォームを閉じる時も 何か設定が出来るのですね(^^♪

    Thin INF_Framework もオートINF_Framework と同じです。

    ↓以下は、FW_オートINF_Framework_MkII.kex の[名札 メイン]に書かれている注意です。

    ※ Thin INF_Framework のプロトタイプでは記述を省略してあります。

     *---------- begin オートINF_Framework ノート ---------------*
     ** オートINF_Framework.wfm/.kev/.cmd IPS_form   第 5.4 版
     ** <ご注意>
     ** 1.以下のイベントハンドラは予約済みです。このイベント処理ファイル( .kev )に、これらのイベントハンドラを作らないで下さい。
     **  フォーム::フォーム開始
     **  フォーム::フォーム終了
     **  フォーム::レコード移動
     **  フォーム::キーダウンン
     **  フォーム::システムキーダウン
     **  フォーム::タイマー1
     **  フォーム::タイマー2
     ** 2.項目名ラベル( lblCaption_1 〜 lblCaption_100 )オブジェクトは変更しないで下さい。
     ** 3.項目テキスト( txtField_1  〜 txtField_100  )オブジェクトは変更しないで下さい。
     ** 4.項目テキスト( txtField_1  〜 txtField_100  )オブジェクトのイベントハンドラは作成しないで下さい。
     ** 5.以下のファミリのベントハンドラは予約済みです。このイベント処理ファイル( .kev )に、これらのイベントハンドラを作らないで下さい。
     **  famCAP
     **  famEZW
     **  famFLD
     **  famRecordUpDown
     **  famSpinButton
     **  famModernUI
     *---------- end  オートINF_Framework ノート ---------------*

    つまり、

    [フォーム::フォーム開始]
    [フォーム::フォーム終了]
    [フォーム::レコード移動]
    [フォーム::キーダウン]
    [フォーム::システムキーダウン]
    [フォーム::タイマー1]
    [フォーム::タイマー2]

    以上の7つのイベントは自作しないでください。

    もしも、これらのイベントハンドラを、イベント処理(.kex)に作ってしまうと、INF_Framework が正しく動作しなくなります。

    特に、[フォーム::フォーム開始]と[フォーム::フォーム終了]のイベントハンドラをイベント処理(.kex)に作ってしまうと、即座に INF_Famework が動作しなくなります。
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    だから、これらのの7つのイベントは自作しないでください。

    ちなみに、これらの7つのイベントは初級者には使い道と使い方が難しいイベントです。また、虫も出やすい厄介な所なんですよ。(^^ゞ

    ということで、INF_Framework を使用する人は、

    [フォーム::フォーム開始]の代用として、[開始時実行コマンド]ボタン(例えば cmdStartup)を使ってください。
                        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    [フォーム::フォーム終了]の代用として、[終了時実行コマンド]ボタン(例えば cmdFinish )を使ってください。
                        ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    p.s.

    どうしても[7つのイベント]のいずれかを使いたい場合には、もちろん対処方法はあります。

    ただし、初従者や上級者のレベルの人にはおススメできませんので、特に公開はしていません。ご了承ください。


引用返信 [メール受信/OFF]
■517 / ResNo.5)  Re[2]: モードレスB で さよなら。モードレスB を閉じる
□投稿者/ ONnoji -(2024/09/19(Thu) 13:09:12)
    2024/09/19(Thu) 13:40:02 編集(投稿者)

    ジェダイの桐さん

    > トレース出力で [HDLCOM]機能 を見ると、
    > 手続きを実行したフォームの手続きが終わる → 相手フォームで when 手続き"フォーム::タイマー2( )"を実行開始しました が始まる
    > という流れが読み取れます。
    > これが
    > ■14365  モジュール化はフォームのレベルでも必要 にある
    >>「イベント駆動型」では、複数のフォームが存在しても、それらは独立していなければならないのです。
    > や
    > 目からウロコのデータベース桐プログラミング入門 の
    > 7 モジュラー設計 にある
    > 「ひとつのモジュールはひとつの機能を担当する」
    > という事なのだと思いました(^^♪

    以前、「データを中心に考えれば失敗しないが、しかし、プロセス(処理)中心に考えると失敗します。」という趣旨の事を書きました。

    これは、[フォームのウィンドウ]も同じですよ。

    脳の中が[プロセス(処理)中心]で考える人は、[フォームのウィンドウ]だってプロセス(処理)の対象なんですね。

    だから、フォームのアッチコッチに余計なオブジェクトを貼り付けて、

    さらに[フォームのウィンドウ]の連携も上から目線で高飛車に強引にやろうとするんですね。

    でも、脳の中が[データ中心]で考える人は、独立したデータである表(.tbx)にフォームをラップ(包む)しただけのものに見えますよ。

    そうすれば、[フォームのウィンドウ]の連携は緩やかなものになると思いますよ。

    そう、すべての[フォームのウィンドウ]は、独立していて干渉し合わない。

    もしも、[フォームのウィンドウ]と[フォームのウィンドウ]の間で何か行う場合には「メッセージを送ればいい」とね。

    [データ中心]で考えていくと、こういう結論になると思うのですよ。

    少なくとも私( ONnoji )はズ〜ット昔からそう考えてきたワケです。アハハハha

    ちなみに、手続きと手続きの関係も同じですよ。(^^ゞ

    「出来るだけ引数を使って結合する」ようにします。でもね、全てにするのは大変なので出来るだけですけどね。

    > 本当に掲示板で相談して良かったと思っていますm(__)m

    私( ONnoji )は、ジェダイの桐さんが解決したい問題は、INF_Framework を使えば簡単に解決できることは最初から気が付いていました。

    でも、何でも自前主義、つまり「車輪の再発明」にコダワル人だったらと心配していたのです。

    そこで、Thin INF_Framework を恐る恐る提案させていただいたのです。

    その結果は、快諾していただけて良かったです。(^^♪

    こういう作品は実際に使う人が現れないとブラシアップ出来ないんですよ。

    こちらこそ、ありがとうございます。m(__)m

    Thin INF_Framework の正式リリースは、まだ当分先になると思います。

    現在、桐sで[リボンを使う]場合に発生する虫の対策を検討中です。

    ということで、まだまだ先になります。

    p.s.

    蛇足ですが・・・(^^ゞ


    INF_Framework 第2.1版 の readme.txt の内容
    ----------------------------------------------------------------
    INF Tools Framework 第2.1版 for 桐ver.8 / 桐ver.9 / 桐ver.9-200X

    INF Tools Framework Rev.72:オリジナル

             By ONnoji Copyright (C) 2003-2008

    【URL】http://www.geocities.jp/siliconvalley_bay_7565/
    ----------------------------------------------------------------

    ■ソフトの種類

     対象:桐のアプリケーション開発者

     種類:フォーム( .wfm )、イベント処理( .kev )、ライブラリ( .cmd )によるフレームワーク

    ■ソフトの内容

    ・一覧表形式や伝票形式のフォームが、表編集のように左右スクロールします。
    ・一覧表形式や伝票形式のフォームが、表編集のように列固定出来ます。
    ・フォームのオブジェクトの幅をマウスドラッグで変更出来ます。
    ※小さいフォント(96dpi) または 大きいフォント(120dpi) で正しく動作します。
    ※その他のサイズのフォントの場合には正しく動作しません。

    ・フォームを最後に閉じた時点のウィンドウのサイズや位置を記憶します。
    ・ブラシアップされたランチャー機能
    ・第2.1版で追加された機能(項目ソート・局所変数値保存・フォーム間通信)
                                ・・・・・・・
                                 ↑
                                これね!

引用返信 [メール受信/OFF]
■518 / ResNo.6)  Re[3]: モードレスB で さよなら。モードレスB を閉じる
□投稿者/ ジェダイの桐 -(2024/09/19(Thu) 14:16:58)
    ONnojiさん


    こんにちは!


    > でも、何でも自前主義、つまり「車輪の再発明」にコダワル人だったらと心配していたのです。


    まさかまさかです(^^♪
    便利機能を知らなかったら、自作の道で頑張るしかないですが
    完成品があって使い方が分かれば 車輪の再発明 をするタイプではないのでありました(^^♪


    > そこで、Thin INF_Framework を恐る恐る提案させていただいたのです。
    > その結果は、快諾していただけて良かったです。(^^♪
    > こういう作品は実際に使う人が現れないとブラシアップ出来ないんですよ。


    想像ですが、Thin INF_Framework を受け入れてくれるユーザーは多い気がします。


    想像の根拠

     ・間口が広い(自作フォームに組み込みやすい)
     ・私が 掲示板 に具体的な使い方を質問し、ONnojiさんが都度具体的解決を提示してくれている
     ・使い方が分かってくれば、ONnojiさん あこめさん のHPに仕様書・使い方の解説があるので便利機能に気付く

    → 結果、 新規開発時は INF_Framework を モダンINF_Framework にして開発する

    の流れが生まれるのじゃないか??
    と、密かに勝手に思っています(^^ゞ

引用返信 [メール受信/OFF]
■519 / ResNo.7)  Re[4]: モードレスB で さよなら。モードレスB を閉じる
□投稿者/ ONnoji -(2024/09/20(Fri) 12:25:33)
    ジェダイの桐さん

    >>でも、何でも自前主義、つまり「車輪の再発明」にコダワル人だったらと心配していたのです。
    > まさかまさかです(^^♪
    > 便利機能を知らなかったら、自作の道で頑張るしかないですが
    > 完成品があって使い方が分かれば 車輪の再発明 をするタイプではないのでありました(^^♪

    ご明察です。

    ところが、実際には完成品というのは、まず一般公開されないんですよね。

    だから、他人の作ったものを利用しようという発想を持たない桐ユーザが多いのかなと思います。

    ちなみに、拙作はフレームワークですから、アプリケーションと勝手が違い、使い道が理解できない人が殆どなんでしょう。

    > 想像ですが、Thin INF_Framework を受け入れてくれるユーザーは多い気がします。
    > 想像の根拠
    >  ・間口が広い(自作フォームに組み込みやすい)
    >  ・私が 掲示板 に具体的な使い方を質問し、ONnojiさんが都度具体的解決を提示してくれている
    >  ・使い方が分かってくれば、ONnojiさん あこめさん のHPに仕様書・使い方の解説があるので便利機能に気付く

    今までフルセットにこだわっていましたから、説明が大変だったんですよ。

    でも、今回はサブセットですから、組み込み方法が簡便で、説明も少なくて済みます。

    大反響なんてことは絶対にないですけれど、そこそこ使ってみようかと思う人も現れるでしょうね。アハハハha


引用返信 [メール受信/OFF]

■記事リスト / レス記事表示 → [親記事-7]






111173

Mode/  Pass/

HOME HELP 新規作成 新着記事 ツリー表示 スレッド表示 トピック表示 ファイル一覧 検索 過去ログ

- Child Tree -
- Antispam Version -