DOWN LOAD BBS

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

■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年の初版から、コンピュータの日進月歩に合わせて、第６版まで改訂され続けたスゴイ書籍です。

    日本での翻訳は、

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

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

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

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

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

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

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

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

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

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

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

    まずは、

    １．Strive for consistency です。

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

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

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

    １．一貫性をもたせる( Strive for consistency )

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

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

    ＜続く＞

引用返信 [メール受信/OFF] 削除キー/
■507 / ResNo.1) 　Re[1]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/09/13(Fri) 15:22:19)
    2024/09/15(Sun) 15:49:34 編集(投稿者)

    【再掲載】

    １．一貫性をもたせる( Strive for consistency )

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

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

    　◇　◇　◇　◇　◇　◇

    これは誰にでも理解できますね。

    でも、実際にそのようにしているか？は、クエスチョンな事が多いハズです。

    　　４．３　タイトルバー
    　　　MS Windows のような OS では、ウィンドウ操作がほぼ共通の操作（ルール）で扱えるからこそ価値があります。
    　　つまり、最初に OS の基本操作を覚えてしまえば、はじめてのソフトでも大体の操作ができてしまうから便利なのです。
    　　　ところが、桐ではタイトルバーを非表示にしたフォームを作ることも可能です。
    　　しかしながら、このような行為はウィンドウ操作を共通の操作で扱えなくするので、「不親切なルール変更」と言わざるをえません。
    　　従って、［フォーム＋イベント処理］のアプリケーションの場合には、タイトルバーを非表示にするのは厳禁です。

    　　【引用】４．３　タイトルバー｜桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
    　　　http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section4

    上の引用のように、

    MS Windows のような OS では、ウィンドウ操作がほぼ共通の操作（ルール）で扱えるからこそ価値があるのです。

    これは、一貫性をもたせる( Strive for consistency )という命題そのものですよね。

    最近でこそ見かけなくなりましたが、［フロー駆動型］の一括処理のアプリケーションでは、タイトルバーが表示されていないフォームが普通でした。

    なぜならば、元々がＤＯＳ桐の画面にユーザが慣れていたこと、

    もう一つ、［タイトルバー］の［×］ボタンをユーザに押させないという意思が働いているからです。

    これは、［フロー駆動型］の一括処理のアプリケーションの特性なのですが、

    一括処理の実行中に開いたウィンドウの［タイトルバー］の［×］ボタンを押すと、制御が一括処理に戻ってしまうのです。

    もちろん、［イベント駆動型］の「フォーム＋イベント処理」では［タイトルバー］の［×］ボタンが押されても何の問題もありませんよね。

    このように、［フロー駆動型］の一括処理のアプリケーションでは、［フォームのウィンドウ］の［タイトルバー］を非表示にすることが多く、

    MS Windowsのウィンドウ操作の共通の操作（ルール）が適用出来なくなるワケです。

    これは、「不親切なルール変更」と言わざるを得ません。キッパリ。
    　　　　・・・・・・・・・・・

    ［フロー駆動型］の一括処理のアプリケーションというのは、そもそもＤＯＳ桐的なものであって、

    キャラクタのスクリーンをグラフィカルなウィンドウに置き換えただけに過ぎないものなのですから、これは仕方ないのです。
    ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    しかし、ＰＣのユーザは桐だけに接するワケではなくて、エクセルやｗｅｂブラウザやメーラ等も使っているワケです。

    そのような使用環境において、Ｗｉｎ桐だけが旧態依然とした所作をしたままというのは、まるでガラパゴス状態ですね。
    　　　　　　　　　　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    桐だけがシーラカンスやカブトガニのようになってしまうのです。
    ・・・・・・・・・・・・・・・・・・・・・・・・・・

    　◇　◇　◇　◇　◇　◇　◇

    さて、［フロー駆動型］の一括処理のアプリケーションの話を終わりにして、［イベント駆動型］の「フォーム＋イベント処理」に眼を向けましょう。

    「フォーム＋イベント処理」では、タイトルバーを非表示にすると、フォームウィンドウを閉じる・最大化・最小化が困難になります。

    もしも、タイトルバーが無ければ、フォームウィンドウを移動させることもままならなくなります。

    だから、まず殆どの人はフォームの［タイトルバー］は表示しているハズです。メデタシ。

    一覧表形式（または伝票形式）のフォームでは、フォームの［オブジェクトの属性］の［フォーム］タブの［最小化］ボタンと［最大化］ボタンのチェックをオンにしてください。

    カード形式のフォームでは、フォームの［オブジェクトの属性］の［フォーム］タブの［最小化］ボタンはオンですが、［最大化］ボタンのチェックはオフにしてください。

    なぜならば、カード形式のフォームを最大化することはまずないからです。

    ＜続く＞

引用返信 [メール受信/OFF] 削除キー/
■508 / ResNo.2) 　Re[2]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/09/13(Fri) 17:22:50)
    2024/09/14(Sat) 17:57:13 編集(投稿者)

    【再掲載】

    １．一貫性をもたせる( Strive for consistency )

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

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

    　◇　◇　◇　◇　◇　◇

    直前では、フォームの［タイトルバー］について考察しました。

    今度は、フォームを閉じる時のボタンについて考えてみましょう。

    またしても、［フロー駆動型］の一括処理アプリケーションの例を取り上げますが、・・・

    桐のウィンドウハンドル番号を用いた一括処理アプリケーションが表示した［フォーム］には、必ずと言っていいほど［閉じる］というキャプションのコマンドボタンがありません。

    その代わりに使われるボタンのキャプションは［終了］です。

    これは、ＤＯＳ桐時代の画面のガイド（キャプション）を引きずった結果とも言えます。

    また、桐のウィンドウハンドル番号を用いた一括処理アプリケーションでは、［コマンドボタンの機能名：一括処理へ戻る］で制御を一括処理に戻すのですから、

    実際の事として［閉じる］というキャプションのコマンドボタンは使わないのでした。

    ということで、もしも［終了］というキャプションのコマンドボタンを見付けたら、これは一括処理のフォームだなと判断してほぼ間違いありません。

    　◇　◇　◇　◇　◇　◇　◇

    さて、［フロー駆動型］の一括処理のアプリケーションの話を終わりにして、［イベント駆動型］の「フォーム＋イベント処理」に眼を向けましょう。

    ［イベント駆動型］の「フォーム＋イベント処理」では、フォームを閉じる操作として、

    　・フォームの［タイトルバー］の［×］ボタン

    　・フォームに配置した［閉じる］ボタン

    　・フォームに配置した［ＯＫ］／［キャンセル］／［はい］／［いいえ］ボタン

    を使います。

    フォームの［タイトルバー］の［×］ボタンはオールマイティーですが、

    ［閉じる］ボタンと［ＯＫ］／［キャンセル］／［はい］／［いいえ］ボタンは使うフォームが限定されます。

    これらのボタンは、［メニューとして使うフォーム］と主ウィンドウに対応する［補助ウィンドウのフォーム］で使用します。

    ［メニューとして使うフォーム］は、単なるランチャーなので、フォームフッタ部に［閉じる］を配置します。

    ［補助ウィンドウのフォーム］は、単なる［ダイアログボックス］なので、

    同じくフォームフッタ部に［閉じる］ボタンや、［ＯＫ］／［キャンセル］／［はい］／［いいえ］ボタンを配置します。

    この手の、フォームを閉じるボタンはフォーム明細部の下部に配置しても良いですが、やはりフォームフッタ部を表示してそこに配置するのが自然です。

    ちなみに、フォームヘッダ部またはフォーム明細部の上部にこれらのボタンは配置しません。

    これは見た目の悪さもありますが、まずウィンドウの上部にこれらのボタンを配置することは一般的ではないからです。

    こういうのを［ルック・アンド・フィール］と言いますが、まず常識的な配置をするのが無難です。

    ＜続く＞

引用返信 [メール受信/OFF] 削除キー/
■509 / ResNo.3) 　Re[3]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/09/14(Sat) 18:53:37)
    2024/09/15(Sun) 15:38:52 編集(投稿者)

    【再掲載】

    １．一貫性をもたせる( Strive for consistency )

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

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

    　◇　◇　◇　◇　◇　◇

    直前では、以下のオブジェクトについて考察しました。

    　・フォームの［タイトルバー］の［×］ボタン

    　・フォームに配置した［閉じる］ボタン

    　・フォームに配置した［ＯＫ］／［キャンセル］／［はい］／［いいえ］ボタン

    今度は、INF_Framework の標準ボタンについて考えてみましょう。

    次のダイアグラムは、NO_FLD_EZW_Plus.wfx のオブジェクトのリストの一部分です。

    　　├ フォームヘッダ部
    　　│　：
    　　│　├ EZWcmdズームイン　　　┐
    　　│　├ EZWcmdズームアウト　　│
    　　│　├ EZWtxtMagnification 　│　
    　　│　├ INFcmdWhoAreYou 　　　├─ 標準のコマンドボタン　※ヘッダ部左上に配置することを推奨します
    　　│　├ HDLVARcmdWhoAreYou　　│
    　　│　├ cmdAlt_I_ズームイン 　│　※ cmdAlt_I_ズームイン と cmdAlt_O_ズームアウト は［画面表示］= しない
    　　│　├ cmdAlt_O_ズームアウト ┘
    　　│　└ ONEcmdUI変換　　　　　 ← オプションのオブジェクト


    これらの［標準のコマンドボタン］と呼んでいるコマンドボタンの内、

    ［(＋)］［(−)］［100%］［？］［？（桃色）］のオブジェクトはフォームヘッダ部の左上に配置することを推奨します。

    これらのオブジェクトは、フォームヘッダ部の｛ 始点X = 3, 始点Y = 3 ｝ポイントの位置に［(＋)］を配置して、［(−)］［100%］［？］［？（桃色）］を２ポイント間隔で配置します。

    もっとも簡単な方法は、NO_FLD_EZW_Plus.wfx の［標準のコマンドボタン］オブジェクトをコピーして、フォームヘッダ部にペーストすればＯＫです。

    ちなみに、始点Y の位置を揃えて、２ポイントの間隔で並べるには、

    あらかじめ［(＋)］［(−)］［100%］［？］［？（桃色）］のオブジェクトを選択してハンドル（黒い■）を表示させてから、

    ［(＋)］のオブジェクトを［ Ctrl + マウス左］でを選択してハンドル（白い□）を表示させて、

    ［書式］メニュー→［レイアウトの変更］を選び、［レイアウトの変更］ダイアログの［配置］タブで、

    ｛ 行数 = 1, 始点X = 3, 始点Y = 3, 水平 = 2, 垂直 = 0 ｝にセットして［ＯＫ］ボタンを実行します。

    ［レイアウトの変更］ダイアログを使わないと、［複数のオブジェクト］を等間隔に並べるのは大変ですので、是非覚えておいてください。(^^ok

    ちなみに、［100%］つまり、［オブジェクト：EZWtxtMagnification］はテキストオブジェクトですが、［EZWcmdズームイン / EZWcmdズームアウト］とセット販売しているオブジェクトです。

    ということで、テキストオブジェクトですが［標準のコマンドボタン］に加えています。

    ［コマンドボタン：cmdAlt_I_ズームイン］と［コマンドボタン：cmdAlt_O_ズームアウト］は、［(＋)］［(−)］と同じ機能ですが、

    アクセスキーの［Alt + I］と［Alt + O］で動作する非表示の隠しコマンドボタンです。

    非表示の隠しコマンドボタン［Ｉ］［Ｏ］は、当然見えませんのでフォームヘッダ部に配置する必要はありません。

    フォームヘッダ部でも、フォーム明細部でも、フォームフッタ部のどこに配置してもＯＫです。

    ただし、ワークスペースに配置するとアクセスキーの［Alt + I］と［Alt + O］は動作しなくなりますので注意してください。

    　◇　◇　◇　◇　◇　◇

    INF_Framework が組み込まれているすべてのフォームのフォームヘッダ部の｛ 始点X = 3, 始点Y = 3 ｝ポイントの位置を起点にして、

    ［(＋)］［(−)］［100%］［？］［？（桃色）］のオブジェクトが配置されている場合、

    どのフォームも同じスタイルなので、フォームの倍率を変える・フォームの情報を見るといった操作をする時に迷子になりません。

    これは、［一貫性をもたせる( Strive for consistency )］という要請に応える事にほかなりません。

    なお、［100%］で表示されている倍率は、INF_Framework が組み込まれているフォームを閉じて再び開いた時に［フォームの倍率］が再現されます。

    また、フォームを閉じる時に［フォームのウィンドウ］が最大化されている場合、フォームを閉じて再び開いた時に［ウィンドウの最大化］が再現されます。

    なお、カード形式のフォームでは、フォームの［オブジェクトの属性］の［フォーム］タブの［最小化］ボタンはオンですが、［最大化］ボタンのチェックはオフにしてください。

    なぜならば、カード形式のフォームを最大化することはまずないからです。

    また、カード形式のフォームでは、フォームの［オブジェクトの属性］の［フォーム］タブの［フォームスクロールバー］のチェックはオフにしてください。

    そうすると、［(＋)］［(−)］を実行した時に、フォーム全体が拡大または縮小するようになります。

    　〔INF_Framework ヒントとコツ〕

    　・フォームを閉じて再び開いた時に、フォームの［フォームの倍率］　　が再現されます。
    　・フォームを閉じて再び開いた時に、フォームの［ウィンドウの最大化］が再現されます。
    　・カード形式のフォームでは、［最大化］ボタンのチェックをオフにします。
    　・カード形式のフォームでは、［フォームスクロールバー］ボタンのチェックをオフにします。

    　◇　◇　◇　◇　◇　◇

    INF_Framework を組み込んだ一覧表形式（または伝票形式）のフォームでは、

    フォームの［オブジェクトの属性］の［フォーム］タブの［ウィンドウのサイズ］を"自動"にしてください。

    そうすると、フォームを閉じて再び開いた時に、フォームの［ウィンドウのサイズ］が再現されます。

    そして、［水平位置の調整］［垂直位置の調整］の両方を"自動"にしてください。

    そうすると、フォームを閉じて再び開いた時に、フォームの［水平位置の調整］と［垂直位置の調整］が再現されます。

    一方、カード形式のフォームの場合には、フォームの［オブジェクトの属性］の［フォーム］タブの［ウィンドウのサイズ］を"フォームのサイズ"にしてください。

    そうすると、フォームを閉じて再び開いた時に、フォームの［ウィンドウのサイズ］は同じままです。※100%以外の倍率では倍率の比例したサイズになります。

    また、［水平位置の調整］［垂直位置の調整］の両方を"自動"にしてください。

    そうすると、フォームを閉じて再び開いた時に、フォームの［水平位置の調整］と［垂直位置の調整］が再現されます。

    　〔INF_Framework ヒントとコツ〕

    　・一覧表形式（または伝票形式）のフォームでは、［ウィンドウのサイズ］を"自動"にします。
    　　⇒フォームを閉じて再び開いた時に、フォームの［ウィンドウのサイズ］が再現されます。　　　　　　　　

    　・フォームの［水平位置の調整］［垂直位置の調整］の両方を"自動"にます。
    　　⇒フォームを閉じて再び開いた時に、フォームの［水平位置の調整］と［垂直位置の調整］が再現されます。

    以上のように、INF_Framework は自動的に［フォームのウィンドウ］を閉じた時と同じ大きさで［フォームのウィンドウ］を開きます。

    なおかつ、自動的に［フォームのウィンドウ］を閉じた時と同じ位置に［フォームのウィンドウ］を開きます。

    この作業は INF_Framework が自動的に行うので、利用者は何も意識する必要はありません。

    INF_Framework は、この作業のために［フォームの編集対象表］と同じフォルダに

    　・フォームの位置
    　・ウィンドウのサイズ
    　・ウィンドウの最大化の有無
    　・フォームの倍率
    　・フォームの背景色

    を記録したテキストファイルを出力します。

    なお、［フォームの編集対象表］が無い［NULLフォーム］ではフォームと同じフォルダにテキストファイルを出力します。

    テキストファイルの名前は、フォームファイル名_編集対象表ファイル名_info.txt です。［NULLフォーム］では フォームファイル名_info.txt になります。

    この INF_Framework が自動的に出力するファイルを、私( ONnoji )は［*_info］と呼んでいます。

    この［*_info］は削除しても構いませんが、［フォームのウィンドウ］を閉じる度に生成されます。

    もしも、［*_info］の内容をリセットしたい場合には、［フォームのウィンドウ］が閉じている時に、［フォームのウィンドウ］に対応する［*_info］を削除してください。

    （重要）［*_info］の内容をメモ帳でご覧になってもＯＫですが、エラーの元になるので内容は変更しないでください。

    　〔INF_Framework ヒントとコツ〕

    　・フォームを閉じると、［*_info］が生成されます。※次回フォームを開く時に自動的に内容が読み込まれます。
    　・［*_info］は、フォームファイル名_編集対象表ファイル名_info.txt または フォームファイル名_info.txt です。
    　・［*_info］は、［フォームの編集対象表］と同じフォルダ、または［NULLフォーム］では［フォーム］と同じフォルダに出力されます。
    　・［*_info］は、削除してもＯＫです。


    ＜続く＞

引用返信 [メール受信/OFF] 削除キー/
■510 / ResNo.4) 　Re[4]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/09/15(Sun) 14:58:18)
    2024/09/15(Sun) 19:02:50 編集(投稿者)

    オプションの［コマンドボタン：ONEcmdUI変換］は、［立体的なＵＩ］と［フラットなＵＩ］を切り替えます。

    ［フラットなＵＩ］は、桐10ｓ以降の桐で作るフォームの標準です。

    INF_Framework では、［立体的なＵＩ］を［クラシックＵＩ］、［フラットなＵＩ］を［モダンＵＩ］と呼んでいます。

    この機能を利用する場合には、"famModernUI" という名前のファミリを作ってください。

    この［ファミリ：famModernUI］は作るだけでＯＫです。

    ［ラベルオブジェクト：lblFlatButtonBorder_1］は、フォームヘッダ部専用です。

    このオブジェクトは、［オブジェクトのリスト］において同じセクションの他のコマンドボタンよりも上位になるようにしてください。

    　　├ ファミリ
    　　│　└ famModernUI　　　← オプションのオブジェクト
    　　：
    　　├ フォームヘッダ部
    　　│　：
    　　│　├ lblFlatButtonBorder_1　← オプションのオブジェクト　※同じセクションの他のコマンドボタンよりも上位になるようにしてください
    　　│　├ EZWcmdズームイン
    　　│　├ EZWcmdズームアウト
    　　│　├ EZWtxtMagnification
    　　│　├ INFcmdWhoAreYou
    　　│　├ HDLVARcmdWhoAreYou
    　　│　├ cmdAlt_I_ズームイン
    　　│　├ cmdAlt_O_ズームアウト
    　　│　└ ONEcmdUI変換　　　　　 ← オプションのオブジェクト

    同様に、［フォーム明細部］専用には［ラベルオブジェクト：lblFlatButtonBorder_2］、［フォームフッタ］専用には［ラベルオブジェクト：lblFlatButtonBorder_3］を使います。

    このオブジェクトも、［オブジェクトのリスト］において同じセクションの他のコマンドボタンよりも上位になるようにしてください。

    これらのオブジェクトは、［ラベルオブジェクト：lblFlatButtonBorder_1］をコピー＆ペーストすれば簡単に作れます。

    ［ラベルオブジェクト：lblFlatButtonBorder_1 〜 3 ］が有ると、コマンドボタンの上にマウスがホバーした時に［ラベルを領した縁取りが］表示されます。

    なお、当然ですがこの機能が利用できるのは、フラットなＵＩが利用できる桐10ｓ以降の桐です。

    　〔INF_Framework ヒントとコツ〕

    　・［コマンドボタン：ONEcmdUI変換］は、［立体的なＵＩ⇔フラットなＵＩ］を切り替えます。
    　・この機能を利用するためには［ファミリ：famModernUI］を作ってください。ファミリは作るだけでＯＫです。
    　・［ラベルオブジェクト：lblFlatButtonBorder_1 〜 3 ］が有ると、コマンドボタンの上にマウスがホバーした時に［ラベルを利用した縁取りが］表示されます。
    　・［ラベルオブジェクト：lblFlatButtonBorder_1 〜 3 ］は［オブジェクトのリスト］において同じセクションの他のコマンドボタンよりも上位になるようにします。
    　・この機能が利用できるのは、フラットなＵＩが利用できる桐10ｓ以降の桐です。

    桐10ｓ以降の桐のフォームの［スタイル名：フラットスタイル1 ］では、コマンドボタンのスタイルは"フラット（縁有り）"が標準です。

    しかし、"フラット（縁有り）"では、マウスポインタがコマンドボタンの上をホバーしてもスタイルに変化がありません。

    これでは、［コマンドボタン］なのか？、［テキスト］なのか？、はたまた［ラベル］なのかサッパリ分かりません。

    従って、どうしてこのようなスタイルが標準になっているのか理解に苦しむところです。

    そのために、INF_Framework では、マウスポインタがコマンドボタンの上をホバーした際に、

    コマンドボタンの背後に［ラベルオブジェクト：lblFlatButtonBorder_1 〜 3 ］を表示して、背景色を"RGB(229,243,255)" にセットします。

    そうすることで、マウスポインタがホバーしているコマンドボタンを分かり易く表示しています。

    　　INF_Framework なし　　　　　　　　 あり　　　　　　　あり　　　　　　　あり
    　　スタイル名　　フラットスタイル1　　モダンＵＩ　　　　モダンＵＩ　　　　クラシックＵＩ
    　　状態　　　　　マウスアウト／イン 　マウスアウト　　　マウスイン　　　　マウスアウト／イン
    　　背景色　　　　RGB(207,216,220) 　　RGB(225,225,225)　RGB(229,243,255)　RGB(225,225,225)
    　　立体色モード　フラット（縁有り） 　フラット　　　　　フラット　　　　　Windowsの立体色

    ＜続く＞



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


    おはようございます！

    スレッドを興味深く読ませて頂いています。


    > 桐のウィンドウハンドル番号を用いた一括処理アプリケーションが表示した［フォーム］には、必ずと言っていいほど［閉じる］というキャプションのコマンドボタンがありません。
    >
    > その代わりに使われるボタンのキャプションは［終了］です。
    >
    > これは、ＤＯＳ桐時代の画面のガイド（キャプション）を引きずった結果とも言えます。
    >
    > また、桐のウィンドウハンドル番号を用いた一括処理アプリケーションでは、［コマンドボタンの機能名：一括処理へ戻る］で制御を一括処理に戻すのですから、
    >
    > 実際の事として［閉じる］というキャプションのコマンドボタンは使わないのでした。
    >
    > ということで、もしも［終了］というキャプションのコマンドボタンを見付けたら、これは一括処理のフォームだなと判断してほぼ間違いありません。


    こちらの解説を読むことで、出来るかどうかは別として

    >ウィンドウ終了コマンドでフォームを閉じる事は、有りなのかが知りたい。

    この考え方は、「 フォーム + イベント 」　では不自然だと言う事が、より理解出来ました(^^ゞ


引用返信 [メール受信/OFF] 削除キー/
■520 / ResNo.6) 　Re[5]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/09/24(Tue) 09:31:07)
    2024/09/24(Tue) 09:38:17 編集(投稿者)

    INF_Framework の｛ウィンドウのサイズ、位置、倍率、最大化｝の自動再現について

    ■｛ウィンドウのサイズ、位置、倍率、最大化｝の自動再現

    　一覧表形式（または伝票形式）のフォームの場合に推奨します。

    　　　属性名　　　　　　：値
    　　　タイトルバー　　　：あり
    　　　ﾌｫｰﾑｽｸﾛｰﾙﾊﾞｰ　　　：水平/垂直
    ［≡］ｺﾝﾄﾛｰﾙﾒﾆｭｰﾎﾞｯｸｽ 　：いる
    ［小］最小化ボタン　　　：いる
    ［大］最大化ボタン　　　：いる
    　　　ウィンドウのサイズ：自動
    　　　垂直位置の調整　　：自動
    　　　水平位置の調整　　：自動
    　　　↓
    　　　└→┌─┬───────┬─┬─┬─┐
    　　　　　│≡│　　　　　　　│小│大│×│
    　　　　　├─┴───────┴─┴─┴─┤
    　　　　　│[+][-]100%[?][?]　　　　　　　│
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　│　編集時の表示倍率：標準　　　│
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　│　ﾌｫｰﾑｽｸﾛｰﾙﾊﾞｰ　　：水平/垂直 │
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　└───────────────┘
    　　　　　│←　ウィンドウのサイズ：　　→│
    　　　　　│　　　自動　　　　　　　　　　│


    ■｛位置、倍率｝の自動再現

    　カード形式のフォームの場合に推奨します。

    　　　属性名　　　　　　：値
    　　　タイトルバー　　　：あり
    　　　ﾌｫｰﾑｽｸﾛｰﾙﾊﾞｰ　　　：なし
    ［≡］ｺﾝﾄﾛｰﾙﾒﾆｭｰﾎﾞｯｸｽ 　：いる
    ［小］最小化ボタン　　　：いる
    ［Ｍ］最大化ボタン　　　：いらない
    　　　ウィンドウのサイズ：フォームのサイズ
    　　　垂直位置の調整　　：自動
    　　　水平位置の調整　　：自動
    　　　↓
    　　　└→┌─┬───────┬─┬─┬─┐
    　　　　　│≡│　　　　　　　│小│Ｍ│×│
    　　　　　├─┴───────┴─┴─┴─┤
    　　　　　│[+][-]100%[?][?]　　　　　　　│
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　│　編集時の表示倍率：標準　　　│
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　│　ﾌｫｰﾑｽｸﾛｰﾙﾊﾞｰ　　：なし　　　│
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　│　　　　　　　　　　　　　　　│
    　　　　　└───────────────┘
    　　　　　│←　ウィンドウのサイズ：　　→│
    　　　　　│　　　フォームのサイズ　　　　│

引用返信 [メール受信/OFF] 削除キー/
■521 / ResNo.7) 　Re[2]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/09/25(Wed) 14:09:26)
    2024/09/25(Wed) 14:33:44 編集(投稿者)

    ジェダイの桐さん

    >>桐のウィンドウハンドル番号を用いた一括処理アプリケーションが表示した［フォーム］には、必ずと言っていいほど［閉じる］というキャプションのコマンドボタンがありません。
    >>その代わりに使われるボタンのキャプションは［終了］です。
    >>これは、ＤＯＳ桐時代の画面のガイド（キャプション）を引きずった結果とも言えます。
    >>また、桐のウィンドウハンドル番号を用いた一括処理アプリケーションでは、［コマンドボタンの機能名：一括処理へ戻る］で制御を一括処理に戻すのですから、
    >>実際の事として［閉じる］というキャプションのコマンドボタンは使わないのでした。
    >>ということで、もしも［終了］というキャプションのコマンドボタンを見付けたら、これは一括処理のフォームだなと判断してほぼ間違いありません。
    >
    > こちらの解説を読むことで、出来るかどうかは別として
    > >ウィンドウ終了コマンドでフォームを閉じる事は、有りなのかが知りたい。
    > この考え方は、「 フォーム + イベント 」　では不自然だと言う事が、より理解出来ました(^^ゞ

    Ｗｉｎ桐の一括処理には、

    Ａ．ＤＯＳ桐で動作する一括処理を［一括処理ウィンドウ］で実行する

    Ｂ．桐のウィンドウハンドル番号を使わないでアプリケーションを作る

    Ｃ．桐のウィンドウハンドル番号を使ってアプリケーションを作る

    の３通りあります。

    Ａは論外として、一括処理を知らない人にとって、ＢとＣの違いは分かり難いです。

    ■桐のウィンドウハンドル番号を使わないアプリケーション

    これは、

    ・［フォーム形式編集］コマンド
    ・［表形式編集］コマンド

    を使うやり方です。

    この場合には、ＤＯＳ桐とほぼ同じなので桐のウィンドウハンドル番号の出番はありません。

    このタイプは簡易的なアプリケーションに多くみられます。

    ■桐のウィンドウハンドル番号を使うアプリケーション

    これは、

    ・［ウィンドウ作成］コマンド
    ・［ウィンドウ会話］コマンド
    ・［ウィンドウ終了］コマンド

    を使うやり方です。

    このタイプは複雑なアプリケーションに多くみられます。

    これは、フォームや表のウィンドウを［舞台の書割］のように使い一括処理側ですべて制御しようとするアプローチです。

    つまり、表示されている［フォームや表のウィンドウ］は、単なる舞台背景と同じ扱いです。
    　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    つまり、銭湯の富士山のペンキ絵と同じなんですよ。
    　　　　・・・・・・・・・・・・・・

    ということで、私( ONnoji )は強烈な違和感を感じて、すぐに一括処理というアプローチを放棄しましたっけ。

    しかし、ＤＯＳ桐時代のアプリケーションを沢山所有している企業・団体では、

    桐ver.7の時に［桐のウィンドウハンドル番号を使うアプリケーション］を大量生産したと思います。

    Windows は 95 → 98 → Me / NT 4.0 → 2000 と急速にバージョンアップして、ＤＯＳ桐を使い続けることが難しくなったことも理由のひとつでしょう。

    遅まきながら、桐ver.8で［フォーム＋イベント処理］というアプローチが可能になりましたが、

    それまでに「桐＝一括処理」というステレオタイプ（多くの人に浸透している先入観や思い込み）が生まれてしまったんですね。
    　　　　　　・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・

    だから、桐ver.8の当時には、［フォーム＋イベント処理］でアプリケーションが作れると思った人は少数派でした。

    一括処理を読めばすべて処理が書いてあるので「一括処理の方が見通しが良い」と思っている人が圧倒的だったんですね。

    ［プロセス（処理）中心］のアプローチが普通に当たり前と思われていたのですから仕方ないですね。アハハハha

    ｐ．ｓ．

    桐には長い歴史があります。

    ということで、コマンドにも

    ・座標指定を伴うＤＯＳ桐由来のコマンド
    ・簡易一括処理（［表形式編集］／［フォーム形式編集］系）のコマンド
    ・拡張一括処理（［ウィンドウ作成］／［ウィンドウ会話］／［ウィンドウ終了］系）のコマンド
    ・それ以外

    とさまざまです。

    だから、［イベント処理］でも使えるからといっても、使わない方がよいコマンドもあるのです。

    それが［ウィンドウ終了］コマンドなのですよ。

    迷ったら拙作ｗｅｂページを参考にしてください。

    こちら
    　↓
    １５　コマンド｜桐の釣魚大全のトップ > フォームアプリケーション教書　第１部
    http://silicon7565.html.xdomain.jp/guide/guide_Part1.htm#section15

    　桐のコマンドにも、Ｗｉｎ桐がコンプレックス( 英:complex 複合の )であることが大きく影響しています。
    すなわち、ＤＯＳ桐と互換の［古典一括処理］と、ウィンドウハンドル番号を用いた［拡張一括処理］と、
    そしてWindowsらしい［フォーム＋イベント］で使えるコマンドが重層的に積み重なっています。


引用返信 [メール受信/OFF] 削除キー/
■522 / ResNo.8) 　Re[6]: INF_Framework の話をしよう
□投稿者/ ONnoji -(2024/09/25(Wed) 15:15:56)
    さて、ベン・シュナイダーマンの書籍の中で紹介されている

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

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

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

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

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

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

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

    ２番めの黄金律は、

    ２．Enable frequent users to use shortcuts です。

    訳すと「頻繁に使うユーザーには近道を用意する」ですね。

    　２．頻繁に使うユーザーには近道を用意する

    　　使用頻度が高くなると，ユーザーは対話の回数やキー入力の数を少なくしたくなる。
    　知識のあるユーサーには省略形，特殊キー，隠しコマンド，マクロ機能などが歓迎される。
    　頻繁に使用するユーザーには応答時間の短縮や表示速度の向上が魅力的である。
    【引用】ユーザー・インタフェースの設計 : 使いやすい対話型システムへの指針｜ベン・シュナイダーマン 著｜日経ＢＰ社　1987｜ISBN4-8222-7053-X


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

    　２．頻繁に使うユーザーには近道を用意する（Enable frequent users to use shortcuts）

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

    これは、具体的には、桐のコマンドボタンのアクセスキーでしょうかね。

    しかし、マウスを使う事が多いので、コマンドボタンのアクセスキーを知らない人だって居ますよね。

    この 8つの黄金律が書かれた当時には、ＧＵＩが普及していなかったのでキー操作に多くの関心が注がれています。

    ［フォーム＋イベント処理］で応答時間を短縮するには、

    ・編集対象表を多重化して作業する

    のが効果的ですね。

    ＜続く＞

引用返信 [メール受信/OFF] 削除キー/
■523 / ResNo.9) 　Re[3]: INF_Framework の話をしよう
□投稿者/ ジェダイの桐 -(2024/09/26(Thu) 11:34:26)
    ONnojiさん


    おはようございます。


    dos桐　でインターネット検索をして画像を見てみました。
    余り画像は有りませんが、何となく当時の雰囲気を感じました。

    それでも、メニュー画面らしき物しかヒットしませんでした。
    なので、［一括処理実行］ウィンドウ　がどんな画面なのか分かりませんでした。


    例えば、

    月末処理.cmd
    月初処理.cmd
    仕入処理.cmd

    みたいに、それぞれの処理毎に　○○.cmd　ファイルがあった感じなのですかね？？

    だとしたら、

    やりたい事を実行するきっかけが、　○○.cmd　ファイル　で　設計者の想定内処理が順番に行われて終了するという感じなのでしょうね。


    桐ver.8　からは［フォーム＋イベント処理］が可能となり

    やりたい事を実行するきっかけが、　オブジェクト　になった
    やりたい事は　○○.kex　ファイルに　プロシージャ　を記述する

    上記の通り　アプローチが　プロセス中心　から　イベント駆動型　となり
    プロセス中心になじみ深い人ほどアプローチの切り替えが難しいと言う事なのだと現状理解しています。


    ｐ.ｓ.

    > 迷ったら拙作ｗｅｂページを参考にしてください。


    基本的に毎日1回は何かしら読んでいるのですが、
    最近読んだ中で、心に響いた章が　8　プロシージャ　です。


    イベントハンドラ　一般手続き　と表現を　プロシージャ　と統一して記載して頂いているので分かりやすいです(^^ゞ　
引用返信 [メール受信/OFF] 削除キー/
次のレス10件＞

スレッド内ページ移動 / << 0 | 1 >>

このスレッドに書きこむ
Mode/　 Pass/

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

- Child Tree -
- Antispam Version -